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

[Paul Eggert]

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?