[tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
eggert at cs.ucla.edu
Thu Sep 16 16:02:52 UTC 2021
On 9/16/21 3:47 AM, Michael H Deckers wrote:
> The charter of tzdb is to provide software
> that represents local times as defined by local authorities.
That is indeed our goal. However, the situation in question has never
occurred so there are no local authorities to consult. So we're trying
to predict what future local authorities will do (a common problem in
My guess is that in the unlikely event that a local authority specifies
a non-minute UTC offset, if we go to that authority and say something
"We can implement two possibilities:
"(A) Your timestamps will be unambiguous, but this will complicate some
obscure calculations on old-fashioned platforms during the trailing part
of a leap-second minute.
"(B) We can simplify those obscure calculations, but your timestamps
will be ambiguous."
then the local authority will pick (A). I doubt it'll pick (B).
Of course I could be wrong. And it's also possible that a local
authority would pick something that's neither (A) nor (B), though it's
unclear what that would be (apparent solar time, perhaps?). From what we
know now, though, I think we're better off implementing (A) than
If this unlikely event ever occurs and local authorities choose
something other than (A), I hope we can adjust tzdb to what they
actually do, much as we already adjust tzdb for other occasions where
local authorities make unexpected changes. (If they choose apparent
solar time I expect we'll be out of luck though....)
More information about the tz