Tim Parenti wrote:
On Wed, 23 Apr 2025 at 05:30, Martin Burnicki via tz <[email protected] <mailto:[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 <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."
I have to admit that I haven't had a closer look at the NIST files and didn't notice this. Anyway, in my opinion it doesn't make much sense because you can't easily see when the file has actually been created.
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.
I think I still have a bunch of old leapsecond files around somewhere, and maybe will have a look at them.
If all versions of the files have different extensions based on the creation date, it's also easier to keep newer and older versions in a single directory, as can be seen for the IERS files.
If all files have the same name and you want to keep older versions, you have to put them into different directories with names associated to the dates or so, or maintain them with some revision control system.
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.
That's much more comfortable, IMO.
On Tue, 22 Apr 2025 at 13:04, Paul Eggert via tz <[email protected]
<mailto:[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.
Agreed.
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.
Agreed, too. Martin -- Martin Burnicki Senior Software Engineer Email: [email protected] Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ MEINBERG Funkuhren GmbH & Co. KG Lange Wand 9 31812 Bad Pyrmont, Germany Registry Court: Amtsgericht Hannover 17 HRA 100322Managing Directors: Natalie Meinberg, Daniel Boldt, Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de https://www.meinbergglobal.com Meinberg - The Synchronization Experts.
OpenPGP_signature.asc
Description: OpenPGP digital signature
