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

[Jacob Pratt]

I believe that the proposed text regarding it not expiring is what would
make most sense. It is forward compatible with any option, after all.

Jacob Pratt


On Wed, Nov 29, 2023 at 2:32 AM Paul Eggert via tz <tz at iana.org> wrote:

> I have a question about leap-second table expiration in TZif files.
> Please bear with a longish explanation first; the actual question is at
> the end of this message.
>
> Since release 2020a, TZDB's zic command has supported "Expires" lines in
> the leapseconds file, and has propagated that info to TZif files using
> an extension to Internet RFC 8536. This extension is a bit of a hack: if
> a TZif file's last leap-second record has the same correction as the
> penultimate record, then the last record is the leap second expiry. For
> example, if the file 'leap-seconds.list' contains the line:
>
>    #@      3928521600
>
> which stands for 28 June 2024; and if you run the command 'make
> EXPIRES_LINE=1 leapseconds', the file 'leapseconds' will contain:
>
>    Expires 2024   Jun     28      00:00:00
>
> and if you then run 'make install', the resulting TZif files with leap
> seconds will contain two leap transitions with correction 27, one
> transition for 1483228826 (representing 2016-12-31 23:59:60 UTC, the
> most recent leap second), and one transition for 1719532827
> (representing 2017-06-28 00:00:00 UTC, the leap second table expiration).
>
> This Expires-line feature was introduced to TZDB in release 2020a,
> replacing an older hack using an "#expires" comment. However, in the
> interest of stability the feature has been disabled by default and you
> must use a non-default setting like "make EXPIRES_LINE=1" to enable it.
>
> Our current draft -09 revision to Internet RFC 8536 documents this new
> feature for the planned version 4 of the TZif file. See
> <https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/09/>
> section 3.2 item "corr(ection)", which says:
>
>    "... in version 4 files with two or more leap-second
>     records, the correction value of the last two records
>     MAY be the same, with the occurrence of last record indicating
>     the expiration time of the leap-second table."
>
>    "The leap-second table expiration time is the time at which the
>     table no longer records the presence or absence of future leap-
>     second corrections, and post-expiration timestamps can not be
>     accurately calculated.  For example, a leap-second table
>     published in January, which predicts the presence or absence of
>     a leap second at June's end, might expire in mid-December
>     because it is not known whether a leap second will occur at
>     December's end.
>
> To complicate matters, a year ago the General Conference on Weights and
> Measures adopted a resolution calling for leap seconds to be phased out
> by 2035 <https://www.bipm.org/en/cgpm-2022/resolution-4>. If this is
> indeed done as late as possible there's a chance we could have our
> first-ever negative leap second before 2035
> <https://insidegnss.com/will-we-have-a-negative-leap-second/> which
> could cause software havoc, and it's not clear whether the authorities
> would go through with this. One more thing: the World Radio Conference
> is currently meeting in Dubai and this meeting may take further action
> regarding leap seconds.
>
> Draft -09 currently has the following text about the possible impending
> demise of leap seconds:
>
>    "If leap seconds become permanently discontinued, as requested
>     by the General Conference on Weights and Measures
>     [CGPM-2022-R4], leap-second tables published after the
>     discontinuation time SHOULD NOT expire, since they will not be
>     updated in the foreseeable future."
>
>
> With all the above in mind, here is my question.
>
> Should TZif leap-second tables have no expiration date if leap seconds
> are discontinued, as draft -09 suggests? Or should they have an
> expiration date of (say) January 2100, which is likely a lower bound on
> the date that the leap-second regime would be replaced by some other
> regime, such as leap minutes? Or should we do something else about TZif
> leap-second expiry after leap seconds are discontinued?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20231129/59b0700c/attachment.htm>