<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#c9">Comment # 9</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 jarko from <a href="show_bug.cgi?id=132083#c8">comment #8</a>) > But in example, we have 2 well defined points, strict up to second. Time > lapse is 10 minutes. No more, no less. No need to truncate or round fraction > of time. Exactly, physically 10 minutes. So one may expect the "conversion" > between time span to time spot will run - I would say - seamlessly. In the > matter of obtaining same results. We have two points in time: 2020-04-13 12:18:00 in LibreOffice is "43934 days since day zero + 12/24 (12 h) + 18/1440 (18 min)" = 43934.5125 (exactly; this is also exactly representable in binary double). 2020-04-13 12:08:00 in LibreOffice is "43934 days since day zero + 12/24 (12 h) + 8/1440 (8 min)" = 43934.505555555555555555... - periodic decimal, not representable exactly in binary (closest binary representation is 43934.5055555555591126903891563, which is slightly *larger* than exact value you intended). Now LibreOffice subtracts these *binary* values (which are approximations of original values; the first approximation happened by accident to be exact, while the second is more usual case, with a small error). The result of subtraction a slightly larger value from exact value is slightly lesser value, right? That is the case here. The result is not exact 00:10:00 (which is 0.00694444444444444... periodic decimal, not representable exactly in binary double), but 00:09:59.999999... (0.00694444443287037... in decimal). Note that this was *always* the case, even before the commit mentioned in <a href="show_bug.cgi?id=132083#c2">comment 2</a>! What has changed after that commit was only the display of that value when using *wall clock* formatting. 09 min 59.9999... s is no more rounded up toward 10 min, but truncated to 09 min *on display*. I had already mentioned that this is the result of inherent floating-point arithmetics operations, which is covered in FAQ (see <a href="show_bug.cgi?id=132083#c1">comment 1</a>). You just need to realize that times are *always* fractional numbers (represented in binary floating points as per IEEE 754), no matter if you think that you enter some "whole numbers" of hours or minutes; and any operations with times are subject to universal floating-point handling rules and gotchas.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>