https://bugs.documentfoundation.org/show_bug.cgi?id=127170
--- Comment #19 from Eike Rathke <[email protected]> ---
First, you may have overlooked that this now since some time (last year) is a
Documentation request to clarify the current implementation and difference of
wall clock / timestamp formats and duration formats. Talking about other means
of how date+time could or could not be implemented in this bug thus is not
helpful at all as it just confuses everyone, especially not so technically
inclined, even more who actually wanted to write a documentation / help
section. Your previous overly lengthy comments from April probably already
scared everyone away.
However..
(In reply to Albrecht Müller from comment #18)
> Assume that t is some floating point number that is used to represent some
> point in time. Then this value is mapped to (round(t*86400) + 0.1)/86400
You don't gain anything by that, it would just introduce errors at other
places. For examples: (output using YYYY-MM-DD HH:MM:SS.00 wall clock format
that does not round)
Input: 2020-02-02
Date serial number: 43863
Your calculation applied: 43863.0000011574
Formatted output: 2020-02-02 00:00:00.10
So far, almost good, *if* ignoring the fractional second *if* no such number
format or calculation asking for it is involved.
Input: 2020-02-02 02:02:02.99
Date serial number: 43863.0847568287
Your calculation applied: 43863.0847581019
Formatted output: 2020-02-02 02:02:03.10
=> bad second value and bad 100th value.
Input: 2020-02-02 02:02:59.99
Date serial number: 43863.0854165509
Your calculation applied: 43863.0854178241
Formatted output: 2020-02-02 02:03:00.10
=> bad minute value and bad second value and bad 100th value.
... and so on.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
