https://bugs.documentfoundation.org/show_bug.cgi?id=172582
ady <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC| |[email protected] --- Comment #1 from ady <[email protected]> --- For an internal serial number of 46132, the "date_only" format corresponds to 2026-04-20. That is "hour zero" for that date. An internal serial number of 46132.9999999999 corresponds to "almost" the end of the same date; it is less than a millisecond before the end of the same date 2026-04-20. So the result in "date+time" format should preferably be consistent with each of its parts, "date" and "time", and also consistent with the "real" point in time for that full internal serial number. If an internal serial number of 46132.9999999999 is rounded to "hour zero" of the "next date" (which corresponds to 2026-04-21 00:00.000) because of precision / accuracy / rounding algorithms, then the results for both "date_only" and "time_only" should also be consistently rounded to the same point in time. But Calc is showing the result as "2026-04-21 23:59:59.999", which is almost 24 hours later than the (rounded) intended point in time, "2026-04-21 00:00:00.000". IOW, the (rounded) time part is incorrect in this case, according to the way the date part is presented. The point in time should be presented either as "2026-04-21 00:00:00.000" or as "2026-04-20 23:59:59.999". The current presentation of "2026-04-21 23:59:59.999" has an error of almost 24 hours. Some rounding methods are better suited for some cases but not for others. Excel might solve this case in one "seemingly adequate" way, but might not be accurate for other cases. This kind of discussions are not new for Calc. Unfortunately, I am not sure whether nowadays there are developers with the adequate experience and knowledge that are still available for Calc development / improvements on this kind of issues, especially without negatively affecting other date+time situations. -- You are receiving this mail because: You are the assignee for the bug.
