OS version: Windows 10
App version: 6.4.1.46
Downloaded from: ONLYOFFICE website
The EOMONTH formula in the spreadsheet editor consistently shows the day before the end of the month. Here is an example for each month in 2020 and 2021 using month-offset values of 0, 1, and -1:
I also included the example from the official help center page on the EOMONTH formula that includes a screenshot of the same formula giving a serialized date of 43496 (1/31/2019), whereas my editor calculates 43495 (1/30/2019).
The same spreadsheet opened in Excel calculates the actual end of month values, but apparently as a new user I can’t include that screenshot as well.
Unfortunately we were unable to reproduce this issue. Please provide us with the file you used for your screenshots, specify the formatting you are using for your date cells and provide us with a screenshot of your “number format” window.
Do you have a place I can upload the xlsx file to, or an email address to send it to? I’m not able to attach it here.
The formatting is the default date format for every value (with the exception of cell G2 just using general formatting to match the help center screenshot):
Specify if the file you provided was initially created using ONLYOFFICE editors.
Specify if this problem reproduces in every newly created (in ONLYOFFICE editor) xlsx file.
Try to open up this file in your ONLYOFFICE editor and click Formula => Calculation => Calculate workbook and see if it changes the output of the formula to the correct value.
Provide us with a screenshot of the File => Advanced Settings… => General tab of your ONLYOFFICE editor.
We also use a locally hosted ONLYOFFICE workspace and it’s experiencing the same bug. I believe we’re on version 11.5.4.1582. I created a brand new spreadsheet directly in workspace and edited it exclusively in the web app and came up with the same results:
If I had to guess based on how broad the issue is and that a European team can’t replicate it, it’s a timezone problem. I’m in UTC-5 and the formula is coming up with a correct date in UTC then shifting it back to my local time before returning the result which is truncated to the day prior.
Working around it by re-adding the missing day means that it’s incompatible with Excel users in the company which we also have. I can think of another more complicated way to calculate an end of the month but it’ll be a lot more steps than running EOMONTH which really should just work as described.
Hello @blehrer
Please accept our apologies for current situation. We are still working on it and we are planning to fix described issue with v.7.4 release.
Please accept our apologies for the amount of time it took to resolve the issue but I’m glad to inform you that it is fixed in new version 8.1 of Desktop Editors.
Update for Desktop Editors will be available shortly. I’d kindly ask you to update editors and check out situation again to provide us a feedback.
I am on version 8.1.0.169. The issue appears partially fixed, but not fully.
If there is no time component to the value, or the time component is before noon, the formula produces the correct result. If the time is on or after 12:00:00, the result is rounded up to the next day, making it the beginning of the following day:
