[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 #23 from Albrecht Müller <albrecht.mueller at astrail.de> ---
(In reply to Mike Kaganski from comment #21)


> the approach I suggested elsewhere to standardize
> on millisecond precision for displaying times
I think you refer to Bug 127334 comment 8 where you propose that some kind of
rounding is necessary. In attachment 160356 I needed a few pages to describe
how Excel might do this "some kind of rounding". Based on this I think:
• The user can choose whatever precision he or she considers reasonable. It is
not necessary do standardize to some precision at all, neither seconds,
milliseconds or whatever.
• There is no need to use different rounding strategies for points in time
(wall clock time) or durations.
• The specification describes precisely the rounding method that has to be
applied. Thus your approach as well as my proposal are incompatible with it.


> incorrect attempt to standardize on 1/10 of a second precision.
There are users who expect correct handling integer arithmetic when using
integer multiples of time units without having to worry about roundoff errors
or distinctions between wall clock times or durations. When using the SECOND
and MINUTE functions other users may expect that a carry goes from seconds to
minutes when seconds are rounded up to the next minute. The workaround is
intended to make those persons happy. The trick is to inject a carefully
crafted error into the input of the current implementation which makes it
return the expected results. Its a kind of proof of concept for the ideas in
the attachment. I chose rounding to seconds due to this specific use case. It
is not a standardization attempt as I think standardization is unnecessary.


> the essense (e.g., what needs documenting here)
If it is unclear if the date and time functions should follow the specification
or should do some kind of rounding that deviates from this specification then
it is pretty difficult to decide what needs documenting.

Just one example how this works: If the date and time functions handle the
carry from seconds to minutes it is not necessary to document this. People
would expect this anyway.

But there is a decision that Calc will will not do this: Bug 127476 had been
closed using the WONTFIX tag. In this case a lot of things need documentation:
• The fact as such: The implementation will lose a carry sometimes.
• What are the situations when this happens?
• From a user’s point of view: What are the benefits of Calc’s way of handling
the carry?
• How date and time calculations are affected? The user should know if the
value is wrong or the formatting.
• Issues with compatibility to Excel, legacy spreadsheets, StarBasic’s date and
time functions, … I stop here to avoid TLDR effects.

-- 
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/20200601/8b69c9eb/attachment-0001.htm>