[Libreoffice-bugs] [Bug 132083] FORMATTING - Wrong date substraction in cell's operation

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Tue Apr 14 11:40:27 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=132083

--- Comment #9 from Mike Kaganski <mikekaganski at hotmail.com> ---
(In reply to jarko from comment #8)
> 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
comment 2! 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 comment 1). 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.

-- 
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/20200414/fbb29f9c/attachment.htm>


More information about the Libreoffice-bugs mailing list