On 6/10/20 2:29 PM, Arthur David Olson wrote:
Anyway, the bottom line is that the stopped clocks make this an oddball transition that cannot be modeled exactly by tzdb
Unless you're willing to have a slew of one-second-apart transitions with each one differing from its neighbor by one second.-)
I thought of that -- that is, specify 9*60 + 21 = 561 transitions that each fall back by 1 second, so that the Parisian clock ticks 00:00:00, 00:00:00, 00:00:00 for 561 extra ticks. But aside from the fact that it'd be overkill to put 561 lines into the database to handle this one little problem, the hack would continue to mishandle subsecond timestamps because a nanosecond-resolution clock would keep ticking up to 00.00:00.999999999 before falling back to 00:00:00.000000000 and that wouldn't model the situation correctly either - it would mean a continuous clock stopped at 00:00 would be correct only 562 times instead of the infinite number of times that it should be correct. Cool that after all these years we've found another real-world historical situation that tzdb doesn't handle. Presumably if you'd known about this back in 1982 you would have added stopped clocks as an extra feature, but I doubt whether it'd be worth it to make that change now....