[tz] If leap seconds go away, should TZif leap-second tables expire?

Robert Elz kre at munnari.OZ.AU
Wed Nov 29 09:16:57 UTC 2023

    Date:        Tue, 28 Nov 2023 23:31:18 -0800
    From:        Paul Eggert via tz <tz at iana.org>
    Message-ID:  <b1216f8c-8fc6-433d-b4da-c8a3f47db402 at cs.ucla.edu>

  | Should TZif leap-second tables have no expiration date if leap seconds 
  | are discontinued, as draft -09 suggests?

I don't think TZif files should have a leap second expiration
date at all, nor should there be any kind of transition at that

I have always interpreted the expiration date in the bulletins as
applying to the bulletins themselves, not to the leap seconds they
advise about.   That's why it makes no sense to continus having
an expiration date in the bulletin if leap seconds are discontinued.
Otherwise a new bulletin would still need to be issued every 6
months, all saying that no leap seconds were being added or deleted
during the validity of the bulletin.

The expiration date that currently exists allows readers to determine
if the bulletin they're reading contains valid data, or if it is
obsolete, and they should go get a newer one - that's all.

Future data in TZif files is always just a guess, it might make
some sense to have data in their indicatinh the time up until when
we believe the data is reliable (more or less the publication
date - lder data might have errors, but those are errors, ie":
bugs, rather than unavoidable).  That might help people determine
if they want to go look for newer data, but unless you want to commit
to always issuing a new release periodically. even if nothing has
changed, it cannot really be an expiration date, just a hint.

What do you believe this field in the TZif files is useful for now?


More information about the tz mailing list