Created attachment 175740 [details] An example of wrong operation of the MINUTE() function A problem with the proper calculation of the MINUTE () function emerged accidentally. I present it in the attached file. When the function determines the number of minutes from the time difference, the result is in some cases a different result than the difference shown when "HH: MM" is formatted. I have this problem in 32 and 64 bit versions on Windows 10
Looks like a rounding issue to calculate the minutes. In G2 =MINUTE(ROUNDUP(B2-A2;6)) seems to work fine. Please, @Eike can you take a look.
Interestingly, if I use the MINUTE(D2) function (D2 contains the formula B2-A2), I get the correct result. If I use the MINUTE(B2-A2) function, some results are incorrect. Apache OpenOffice (4.1.11) does not have this problem.
This issue is documented at https://wiki.documentfoundation.org/Faq/Calc/Accuracy In the example linked 2020-04-13 12:18:00 - 2020-04-13 12:08:00 is calculated into cell A3 and then "Cell A3 will show 00:09:59.999999 instead of expected 00:10:00.000000 if formatted using [HH]:MM:SS.000000 format string. This happens despite only whole numbers of hours and minutes were used, because internally, any time is a fraction of a day, 12:00 (noon) being represented as 0.5. The data in A1 is represented internally as 43934.5125, and in A2 as 43934.5055555555591126903891563 (which is not exact representation of the entered datetime, which would be 43934.505555555555555555...). Their subtraction results in 0.00694444443287037, a value slightly less than expected 0.00694444444444..., which is 10 minutes." So its a more fundamental problem with using a binary number to represent fractions of a day which can't be done exactly.
This is yet another example of issues manipulating dates stored as reals. *** This bug has been marked as a duplicate of bug 125580 ***
Created attachment 175847 [details] just some comments and samples what to consider doing time calculations in calc -- see in the sheet --
I don't think it is a duplicate, here there issue is with MINUTE() function calculation not about sum time values. I think using the same formula used to calculate the minutes in time format, could solve the problem, as the cell format gives accurate results. -------------- (In reply to b. from comment #5) > ..... With =MINUTE(ROUNDUP(B15-A15;6)) gives a good result for the six cases. Apparently on the sixth decimal, periodic decimals for minutes values begin, and rounding up to 6th decimal before the function calculation the minutes seems to get good results.
Dear Jerzy Moruś, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug