hi @all,
i apologize for again having ‘exotic’ problems and silly questions … i had calculation oddities with a start date of 1970-01-01 for a series of timestamps , and got it boiled down to:
‘=24568’ interpreted as a day is 1967-04-06, subsequent integers stand for subsequent days,
‘=1/144’ is an ‘odd’ endless fraction 0,00694444444444444(4), and interpreted as a day fraction equals ~10 minutes (best possible representation in calc),
‘=24568 + 1/144’ formatted as ‘JJJJ-MM-TT" T "HH:MM:SS,000000000000000’ yields
‘1967-04-06 T 00:10:00,000000000000000’, that’s well, and applies for almost all day values from 0 up to today (44300) (disclaimer: i didn’t check em all).
but for a special range, from 24569 to 25568, corresponding to dates 1967-04-07 til 1972-09-26, the sum (say) ‘=24569 + 1/144’ results in e.g. ‘1967-04-07 T 00:10:00,000000099999966’ and the like, all the same fractional string.
i’d say i’m not ‘too bad’ in understanding FP’s and deciphering their oddities, but above is puzzling me. i know it’s a small deviation near the limits of doubles, and wouldn’t be astonished if the difference would come up around a decimal or binary range change?, or would grow grow or shrink in the chain?, but cannot find any source in the values or bits … thus i suspect a weakness in the conversion ‘number to date string’.
could please the one or other reader do a recheck before i file a bug? thanks a lot.
pls. do not! … tell me FP-math is imprecise in general, i know! that but am looking to distinguish between FP- and programming errors so that not too many programming errors remain unprocessed as “it’s just FP, they’re always to blame”