[Libreoffice-bugs] [Bug 127170] Clarify clock time (HH:MM, MM:SS, ...) and duration time ([HH]:MM, [MM]:SS, ...) formatting in help; (ignore the MM month vs minute discussion)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=127170

--- Comment #27 from Albrecht Müller <albrecht.mueller at astrail.de> ---
The misinterpretation may come from taking a users point of view: In the bug
report Jaromir essentially subtracted 8 minutes from 18 minutes, expected 10
minutes, saw 9 minutes. Clearly not consistent with elementary integer
arithmetic. Then he learns that he will see the correct 10 minutes if he uses
(right) duration format instead of (wrong) wall clock format. No intention to
hurt anyone. Sorry.

> it doesn't discuss the problem as
> formatting problem, but rather as computational problem when
> performing spreadsheet operations with date/time values.

Seems that I did not distinguish between the two things clearly enough: The
computational problem is that Calc represents date and time values as floating
point values only and processes these values in the same way as any other
floating point values. So I have no problem with a calculation like "1900-01-01
* 1900-01-02 = 1900-01-05" as this is - using a different number format and the
right date base - the same as 2 * 3 = 6.

Being able to use floating point arithmetic for performing date and time
calculations is a key design feature which you cannot take for granted. That's
why I listed the seemingly trivial restrictions that make feature possible.

Of course, these floating point values in general cannot represent date and
time values exactly. Therefore you need some way to deal with these
inaccuracies in some reasonable way. This problem appears both as a formatting
problem as well as a computational problem in date and time functions like
SECOND/MINUTE etc.

ad 1) Don't forget that besides SECOND, MINUTE, HOUR, DAY, MONTH and YEAR there
are some more date and time functions that also should use the same rounding
strategy. Otherwise they may return inconsistent results.

ad 2) Agree

ad 3) I don't understand why you want to settle on a fixed 1/1000 of a second.
The math I tried to develop does not distinguish between representations where
seconds have or don't have a fractional part. Not having a fractional part is
equivalent to having a fractional part containing zero digits. Therefore my
idea is to have a set of elementary functions that use the number of digits in
the fractional part as a parameter. This way you need only one implementation
which is the basis of all the other functionality. In 1) you argue that the
SECOND/MINUTE etc. functions should always round to the nearest second. This
would be equivalent to use a parameter that specifies zero digits in the
fractional part. You can use these functions for formatting too. In this case
the parameter is the number of digits required by the format, which may be zero
(no fractional part) or more (if there is a fractional part). I think this
results in a behaviour which is equivalent to the common representation of
floating point numbers where the same number may be represented by "2", "1.9",
"1.94" or "1.936" depending on the number of digits required. If there is a
need to use a fixed resolution of 1/1000 of a second simply use 3 for this
parameter.

ad 4) That's probably a lot of work.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200909/26eb23d2/attachment.htm>