[tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
Paul Eggert
eggert at cs.ucla.edu
Mon Sep 13 18:49:03 UTC 2021
On 9/13/21 2:45 AM, Robert Elz wrote:
> do the changes in this proposal also correctly handle negative
> leap seconds that are (for whatever bizarre reason) shoved into the middle
> of a minute?
Good question. I don't know of any problems in that area, though, as the
proposed change does not affect negative leap seconds.
The problem with 2021a and earlier is that localtime labels are
ambiguous in a positive leap second inserted into the middle of a
localtime minute; for example, if a leap second is inserted between
seconds 11 and 12 the count is ... 9, 10, 11, 11, 12, 13,... which is
problematic.
With a negative leap second, the clock skips a second so there can be no
ambiguity and there is no need for a fix. If the 11th second is skipped,
for example, the localtime seconds is simply ... 9, 10, 12, 13,.... This
has long been the case in the code, and the proposed change does not
affect this.
More information about the tz
mailing list