[tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute

[Paul Eggert]

On 9/13/21 6:38 AM, Michael H Deckers wrote:
>      Isn't it quite simple to compute the fictitious local time LT:
>      when UTC is 1972-06-30T23:59:59Z then LT is 1972-07-01T01:23:44
>                  1972-06-30T23:59:60Z then LT is not well-defined

If we took that approach, shouldn't calls to 'localtime' fail during a 
positive leap second? After all, localtime is not well-defined.

Clearly we can't do that; too much code expects localtime to succeed 
unless the time_t value is extremely large or small. localtime must 
generate *something*, even though it's bogus according to the 
abovementioned approach. Unfortunately, whatever value localtime 
plausibly generates will lead to ambiguity in timestamps. And ambiguity 
is a real problem for users.

If I understand things correctly, you're saying that if the UTC offset 
is a multiple of 60 seconds, then localtime is well-defined during a 
positive leap second because it ends in :60. Otherwise, localtime is not 
well-defined during a positive leap second.

The proposed patch generalizes in a better way. It says that localtime 
is well-defined at all times: the minute containing the leap second has 
seconds numbered 0 through 60, with the leap second being one of those 
seconds. There is no ambiguity about which second a localtime label 
identifies, and no second in which localtime is undefined. And the UTC 
offset remains constant.

>      In your proposal, LT - TAI and UTC - TAI have discontinuities at
>      different values of TAI so that LT - UTC just cannot be constant.

Such a problem doesn't occur if one uses a proper mapping from 
broken-down time to seconds counts. In the proposed patch, the mapping 
from broken-down time (date, hours, minutes, seconds) to LT (a seconds 
count) takes a within-minute positive leap second into account. LT - UTC 
is constant because LT - TAI and UTC - TAI have discontinuities at the 
same instant. Please see my recent email to John Sauter for another way 
to look at this.


In thinking about this more, we have a tradeoff here. When dealing with 
positive leap seconds, is it more important to have unambiguous 
timestamps, or to have a simple way to calculate UTC offsets without 
using tm_gmtoff? If the former, the proposed patch is better; if the 
latter, then 2021a is better.

For end users I think it's quite clear that unambiguous timestamps are 
better.

If there's a real need to calculate UTC offsets without using tm_gmtoff, 
I think one can write a function to do that that will work even with the 
proposed patch present. Such a function isn't needed for current tzdb, 
though, since the situation in question cannot occur in the existing 
database. So writing such a function should be low priority.