EOMONTH() produces different results than MS Excel

[brandon-avantus]

This issue is unique.

• I have used the search tool and did not find an issue describing my bug.

Operating System

Linux (DEB package)

Version information

8.0.1.31

Expected Behavior

Entering the formula =EOMONTH(DATE(2028, 1, 1), -3) in MS Excel produces the expected date 10/31/2027 (or the integer 46691). I would expect the same from ONLYOFFICE.

Actual Behavior

Entering the same formula in an ONLYOFFICE spreadsheet produces the date 10/30/2027 (or the integer 46690), which is one day earlier than expected. I tried this with other dates as the first parameter and other negative months as the second parameter with similar results: the second-to-last day is returned instead of the last day.

Reproduction Steps

1. Create a new ONLYOFFICE spreadsheet
2. In any cell, enter the formula =EOMONTH(DATE(2028, 1, 1), -3)
3. Set the cell format to Short Date

Additional information

See the official MS EOMONTH documentation.

Note: I am using the Flatpak version of ONLYOFFICE Desktop Editors from flathub, not the DEB package as indicated; there is no option for Flatpak in the OS list.

[rsnegirev]

Hi @brandon-avantus

What regional settings do you use?

[brandon-avantus]

What regional settings do you use?

Also,

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

[rsnegirev]

Sorry for a long answer, @brandon-avantus.

What is your GMT zone?

[brandon-avantus]

What is your GMT zone?

$ cat /etc/timezone
America/Los_Angeles

@rsnegirev current GMT adjustment, due to daylight saving time, it is -0700 (US PDT).

[rsnegirev]

@brandon-avantus sorry for a long answer.

The problem was fixed in this commit: ONLYOFFICE/sdkjs@b1eb1bb

Fixes will be released in the next major version.

And we're moving this issue to DocumentServer repo, since it's our base product and problem actual there too.

Thank you for the report!

[brandon-avantus]

Thank you for the quick fix!