https://bugs.documentfoundation.org/show_bug.cgi?id=127334
Albrecht Müller <albrecht.muel...@astrail.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|NOTABUG |FIXED
--- Comment #2 from Albrecht Müller <albrecht.muel...@astrail.de> ---
The help information that explains the minute function
(https://help.libreoffice.org/6.3/en-US/text/scalc/01/func_minute.html?&DbPAR=CALC&System=WIN
) simply states "MINUTE Calculates the minute for an internal time value. The
minute is returned as a number between 0 and 59." and specifies "=MINUTE(8.999)
returns 58" and "=MINUTE(8.9999) returns 59". Especially it does not refer to
the document
https://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html#MINUTE
that provides a some more information about the minute function. It does not
even mention things like wall clock time or durations. This gives you a lot of
freedom to declare some behaviour as correct and you are free to change the
behaviour from version to version. Therefore closing this report as "NOTABUG"
is completly ok.
On the other hand: Doing so has some pretty nasty consequences from a users
point of view, and that's why I filed bug 127170.
First: I did this kind of trivial time calculations with different spreadsheet
programs (including LibreOffice Calc up to version 6.0.4.2) and they all were
able to come up with correct minute values. As long as this worked as expected
I did not care how this was achieved. I assume that they internally rounded
float values to some internal time resolution before they interpreted them as
time and/or date. If this resolution is choosen such that it is some orders of
magnitude above the floating point round-off errors these errors will affect
the result in extreme cases only. The programming language Java does date/time
calculations based on integral numbers of milliseconds to avoid round-off
problems altogether. Closing this bug as "NOTABUG" tells me that LibreOffices
quality standards allow time calculation algorithms to deliver zero or one
minute with equal probability when subtracting e.g. two minutes from three
minutes.
Second: This problem affects all functions of this kind. A round-off error in
the sub-milliseconds range may cause the year function to return the wrong
year. The key problem is that usually integral numbers of time units (years,
month, days, hours, minutes and seconds) are considered and therefore the
calculations could be exact. However, LibreOffice uses a time representation
that cannot guarantee an exact representation of the time units hours, minutes
and seconds.
Third: I cannot trust the results of LibreOffices date/time calculations any
more. Any legacy spreadsheets containing this kind of simple time calculations
will deliver wrong results if opened with recent versions of Calc. What makes
the matters worse is that the user documentation does not specify how Calc is
intended to handle the problems rooted in its time representation and obviously
this intention changes from time to time. Therefore I cannot know how to use
the date/time calculation functions in a way that future version of Calc will
return the same results even if I assume that these functions are implemented
correctly.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
