Created attachment 169167 [details] example for one-second-less-behaviour In the attached ods you can see that for - a few years - everyday - but only for some hours a)) 1) DATE(<year>;1;1) evaluates correctly 2) TIME(<hour>;0;0) evaluates correctly 3) the sum of both evaluates to one second less than expected b)) 1) DATEVALUE("01.01.<year>") evaluates correctly 2) TIMEVALUE("<hour>:00:00") evaluates correctly 3) the sum of both evaluates to one second less than expected This might be related to #127498, but there the TIMEVALUE(...) itself is reported to be one second less whilst herein only the summations are. Best regards Ian
Thank you for reporting this issue. I can confirm that version Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Mac OS X 10.15.7; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded has the same behavior. I am not sure it is a bug, however. It looks like a rounding problem, and I do not know the details of the way dates and times are represented in LibreCalc, so I cannot really evaluate whether it is a rounding problem or not. For what it is worth, opening the ods file with Microsoft Excel for the Mac version 16.16.18 does not show this problem.
I did a bit more digging and found https://bugs.documentfoundation.org/show_bug.cgi?id=127334 From the comments there, problems with time values caused by rounding is a known issue, with no perfect solution. So the behavior demonstrated here is probably not a bug (for some value of "bug").
@Eike, I thought you might be interested in this issue
Hard to understzand. I traced the examples =VALUE("1972-09-26")+TIME(2;0;0) which has an even serial nuzmber (26568) relative to default nulldate. and =VALUE("1972-09-27")+TIME(2;0;0) down to the IEEE 754 Double bit-pattern 64 bit). The patterns were identical with the exception of the one bit for the additional day in the second case (14th bit of the mantissa). Using the code "HH:MM:SS.00000000000" value-INT(value) was formatted to 01:59:59.99999989500 in both cases. The full date-time, however was formatted differently as the reporter described. I can't see any possible effect of rounding or error accumulation ... explaning the experiences. There must be a rather smart bug inside the date-time-formatting routine. Since date-tiume-values are generally rounded DOWN for the display, there should be a branch limiting the effect to some fraction of a second, and this way avoiding the "59.999.... s" where a full minute must be expected. However this branch must be skipped for unknown reasons in rather rare cases. The mentioned bit patterns (LSbit right) were 0 10000001101 1001111100100000010101010101010101010101010101010101 and 0 10000001101 1001111100100100010101010101010101010101010101010101 respectively.