https://bugs.documentfoundation.org/show_bug.cgi?id=168673
Mike Kaganski <mikekagan...@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Mike Kaganski <mikekagan...@hotmail.com> ---
In Version: 25.8.2.2 (X86_64)
Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f
CPU threads: 24; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan;
VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL threaded
the "Using floating point fails" section works for me (shows 1, as expected).
For the "Using floating point with Time-Format fails" section, it indeed shows
0. However:
1. I can't understand what "Seems to happen if the item is at the end, with a
slightly larger area, it works" means specifically. I tried to change the
formula in C11 to =COUNTIFS($A$7:$A$12;"="&$A11), and it fails likewise. The
formula in C12 is comparing an empty cell to an empty cell, so is unrelated.
2. It is not actually about "being at the end" - it seems specific to the
concrete time value of '01:26,47' - which fails, wherever in the range it is
(e.g., extending the formula in C11 to C7:C11, and copying the value of
'01:26,47' to A9, makes C9 also show 0).
3. Even changing number format of A11 to Standard doesn't change the
recalculated result of C11.
4. It seems to be very unusual. The following formula also shows FALSE:
=A11=VALUE(TEXT(A11;"Standard"))
and the following formula shows -2,31481481481481E-14:
=A11-VALUE(TEXT(A11;"Standard"))
Note that formatting A11 as Standard shows this number:
0,00100081018518519
and a formula like =TEXT(A11;"Standard") shows this text:
0,00100081018518519
both look identical, and - what's important - have 17 digits after decimal; so
the reported difference of 2E-14 is completely unexpected.
--
You are receiving this mail because:
You are the assignee for the bug.
