[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