[tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
eggert at cs.ucla.edu
Mon Sep 13 19:26:28 UTC 2021
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
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.
More information about the tz