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

Paul Eggert 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.

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.

```