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