Created attachment 125697 [details] test file Steps> open attached file .ods save as xlsx open in excel Results are different.
Created attachment 125698 [details] printscreen from excel
Created attachment 125787 [details] test document with extra use cases Document used for testing the bug fixes.
(In reply to Winfried Donkers from comment #2) > Document used for testing the bug fixes. Note that cell C23 has =IFERROR(A23,1) instead of ISERROR(A23), so any value other than error in A23 will be propagated and later evaluated as TRUE if not 0.
Btw, it would tremendously ;) help if all test case documents used English UI function names and separators in their FunctionString column and documents were formatted using the English-US locale from the number format settings (best modify the Default cell style to use English-US General before starting things) so result strings are TRUE instead of some other language's word and display strings use '.' dot decimal separator, and furthermore explicitly format all dates as ISO yyyy-mm-dd to prevent confusion. For why en-US locale: otherwise when someone in another default locale than the original locale edits the document, the saved version creates an unnecessarily large diff (at least of all display strings) if it is to be submitted as a change to the git repository.
@Raal: I leave the improvements to the unit test documents to you, my attachment #125787 [details] was merely informative.
Created attachment 126007 [details] test document with extra use cases Attached file contains extra use cases to make sure that the results from Excel and Calc are the same. Expected results in the document are the results from Excel 2016 and Excel Online.
Winfried Donkers committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=696b515dcfe9e003037370b99e3ba8d2c9c20c28 tdf#100446 fix compatibilty issues with Excel. It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Resolution target 5.3.0. However, please re-check the following: 1) Bad results when there are overlaps between user-defined WEEK-END options and one or more dates in user-defined holiday list. For example, if WEEKEND code 11 is used (i.e., Sunday-only weekend) and if some of the holiday dates happen to be Saturdays, then the results ignore the holiday. Saturday is treated as working day, giving priority (or so it seems) to the WEEK-END code that defines Saturday as a working day. All Saturdays that are declared as holidays should not be counted among working days. Not doing so, gives wrong results. 2) I have checked, the above problem for Sunday only weekend. However, before finalising the code, please ensure that it is bug-free for all the options of WEEK-END codes other than the default (2 to 7, 11 to 17). 3) LibreOffice 'freezes' (Windows 10) when the invalid string "1111111" (seven ones) is used, instead of returning an ERROR-CODE Not attaching a sample file, since the issue is already known. This is a reminder for double-checking before the next release.
Please attach test files where current code fails. Thanks.
Created attachment 128189 [details] FUNCTION WORKDAY.INTL implementation, faulty/ inconsistent results WORKDAY.INTL Worksheet showing errors
(In reply to Chandanathil P. Geevan from comment #10) > Created attachment 128189 [details] > FUNCTION WORKDAY.INTL implementation, faulty/ inconsistent results > > WORKDAY.INTL Worksheet showing errors I opened your document with Calc (version 5.3, master) and with Excel Online. Both produce the same results in the rows that you marked as WRONG in column N, but not always the results that you noted as expected in column P. I did however notice that the results in your document (i.e. as calculated by the Calc application you used) differ from the results I got. Which version of LibreOffice did you use to produce your document? As target:5.3.0 indicates, the bug fix for this bug report will only be in releases of version 5.3.0 and later.
Regrets for delayed response. The bug was reported by users in versions 5.2 and older. It has been resolved (I haven't personally checked) as reported by a user. He is the one who informed me of this problem. He says it is resolved in the latest "Fresh" version 5.2.3.3. Hope this answers tour query.