<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - FORMATTING - Wrong date substraction in cell's operation" href="https://bugs.documentfoundation.org/show_bug.cgi?id=132083#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - FORMATTING - Wrong date substraction in cell's operation" href="https://bugs.documentfoundation.org/show_bug.cgi?id=132083">bug 132083</a> from <a class="email" href="mailto:mikekaganski@hotmail.com" title="Mike Kaganski <mikekaganski@hotmail.com>"> Mike Kaganski</a> <pre>(In reply to Aron Budea from <a href="show_bug.cgi?id=132083#c2">comment #2</a>) > Interestingly it displayed 0:10 in both cases before the following commit > (just noting here): > > Use tools::Time::GetClock() in number formatter for wall clock time Yes, that was the intended change. The idea is this: when people talk about datetimes, and want to express that in hours and minutes, they say "2020-04-13 23:59" even when it's "2020-04-13 23:59:58". They will not say that it's tomorrow's day when it's still 2 seconds to it left. Outputting that as "00:00" is wrong. Thus, when formatting wall clock times, it doesn't get rounded up, but truncated. This makes tiny floating-point inaccuracies (when the nearest floating-point value is slightly less than exact value) to result in this. See also <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Regression: Incompatible changes in date/time arithmetic introduced between Version: 6.0.4.2 (x64) and version 6.2.6.2 (ubuntu)" href="show_bug.cgi?id=127334#c8">bug 127334 comment 8</a>, where I suggest to limit the precision of time formatting, to avoid this.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>