On Wed, 23 Apr 2025 at 05:30, Martin Burnicki via tz <[email protected]> wrote:
> According to the original specification presented by Judah Levine and > Dave Mills in 2000 (a copy can be found here: > http://time.kinali.ch/ptti/2000papers/paper34.pdf), > the file contains a special comment line starting with "#$", indicating > the last modification date of the file, in NTP format. > … > Although the leap second file released by NIST yesterday states in the > comments: "Updated by IERS Bulletin C69", the original file name is > "leap-seconds.3676924800", and also the "last update" timestamp in the > file is > > #$ 3676924800 > > which means "2016-07-08 00:00:00" > > which obviously doesn't refer to the time when the file was really > updated, namely yesterday. > The NIST flavor has long referred to the #$ value as "the date on which the most recent change to the leap second data was added to the file", so 2016-07-08 is indeed the correct value in this case. The comments explicitly state that "[the] update procedure will be performed only when a new leap second is announced" and that, "[i]f an announcement by the IERS specifies that no leap second is scheduled, then only the expiration date of the file will be advanced to show that the information in the file is still current -- the update time stamp, the data and the name of the file will not change." Although NIST's server doesn't have old versions of the file available, I can confirm that all of this language was present from when Paul first put it into the repository in 2013 <https://github.com/eggert/tz/commit/459b72d3edec98488e5132d4473c4678b4ed5a73> until we switched to the IERS format in 2024. All of the different versions we'd committed from NIST over the years only updated this value when there was new data (i.e., a new leap second). I'm not sure where the deviation from the specification originated, but it was before 2013, and the #$ update value has since been consistently used in NIST's version as its surrounding comments describe. By contrast, the IERS flavor just describes the #$ value as "the last update of this file" and currently gives 2025-01-07, which is also correct for that simpler interpretation as specified by its comments. On Tue, 22 Apr 2025 at 13:04, Paul Eggert via tz <[email protected]> wrote: > Although NIST's longer expiration date would be better for TZDB I do, however, share Martin's concerns with NIST's stated expiration date of 2026-06-28. I'm not convinced that it is actually valid for most intended processing purposes. Although anyone watching UT1−UTC with any care could intuit that the odds the IERS will announce a leap second for 2025-12-31 are *approximately* 0%, they are not yet *equal* to 0% and won't be until IERS actually makes that announcement in July. To my eye, the whole point of the expiration line is to encourage clients to do an explicit re-check prior to the next possible date for which no announcement has yet been made, as IERS does not issue advance guidance on leap seconds other than saying "Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date." In particular, the comments in the IERS file simply describe the #@ value as the "[e]xpiration date of the file", while the NIST flavor goes into much more detail on exactly what that expiration date is supposed to indicate — detail which appears not to have been followed with this week's update. All past NIST practice would indicate to me that this value should encode 2025-12-28 until after IERS formally makes its announcement about 2025-12-31. (I've attached the latest versions of both files I've grabbed for the reference and convenience of those interested.) -- Tim Parenti
leap-seconds.IERS.list
Description: Binary data
leap-seconds.NIST.list
Description: Binary data
