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?