https://bugs.documentfoundation.org/show_bug.cgi?id=127170
--- Comment #4 from Albrecht Müller <albrecht.muel...@astrail.de> ---
(In reply to Eike Rathke from comment #3)
>
> This is a bit nasty as using both the [MM] and the M codes in one format
> seems to trick out the type detection, i.e. after defining it the format at
> ...
I don't really care if this behaviour is a bug or not as this is a bug report
against the documentation and not against a particular behaviour of Calc. The
key problem here is that the help function does not specify how to deal with
ambiguous format strings: Should Calc consider these strings as illegal and
treat them as an error? Or should it use some default interpretation? How to
deal with a situation where you want minutes values at position where Calc
would interpret it as month value? What are the exact rules to resolve the
ambiguities?
I stumbled over this problem when I found your comment
https://bugs.documentfoundation.org/show_bug.cgi?id=125099#c8 and tried to find
out the difference between "[HH]" and "HH" in the context of duration and wall
clock time. The help information
https://help.libreoffice.org/6.3/en-US/text/shared/01/05020301.html?DbPAR=SHARED#hd_id3155870
states that "HH" are between 00 and 23 while "[HH]" may deliver values above
23. It says nothing about durations or wall clock time, and nothing about
possibly different rounding behaviour. I think this is a defect in the
documentation - users cannot know the kind of difference you mention in your
comment.
Date/time calculations are tricky. A special problem is that these calculations
normally use integral quantities of time units and therefore exact calculations
are possible. Calc represents date/time values as float numbers. One day
corresponds to the value of one. Hours, minutes and seconds correspond to
values less than one. In general, points in time that correspond to a
combination of integral numbers of hours, minutes and seconds have no exact
representation as floating point values. Therefore date/time calculations
usually contain round-off errors. Nevertheless all spreadsheet programs I used
so far - including LibreOffice up to version 6.0.4.2 - delivered exact values
when I did some simple date/time calculations. There is a defect in the help
function as it does not specify how Calc is expected to handle date/time
calculations, i.e. the behaviour of date/time calculations is undefined. A
nasty consequence of this fact is a recent change the date/time calculation
algorithm. This algorithm used to deliver a difference of one minute if you
subtracted two timestamps that were one minute apart. The new algorithm returns
essentially a random value which is 0 or 1 minute with about 50% probability
each (see bug 127334) which breaks all legacy spreadsheets that contain this
kind of calculations. As the user documentation does not specify a correct
behaviour the behaviour of the new algorithm can be classified as "NOTABUG".
--
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
