Hello,
Thanks for your note.
I don't know how many people use the file that I publish or if the number
of users is approaching a NULL set. But the definition of the "last modified"
date was based on user opinions that this was a useful way of describing the
data, and I would not want to make a change to this parameter that broke some
application somewhere.
The expiration date of the file is a different matter. As I mentioned in my
previous note, it is intended as an emergency off switch if the normal upgrade
process fails for some reason. It could be shortened without having any
operational consequences almost all of the time. I would consider changing this
if the community has a strong opinion about this.
The hassles associated with ftp are very annoying to me as they are to at
least some of you. This is out of my control. Based on history around here,
this sort of stuff tends to get worse.
Best wishes,
Judah Levine
-----Original Message-----
From: Paul Eggert <[email protected]>
Sent: Thursday, April 24, 2025 1:44 PM
To: Levine, Judah Dr. (Fed) <[email protected]>
Cc: Time zone mailing list <[email protected]>; Tim Parenti <[email protected]>
Subject: Re: wrong last-modified timestamp in NIST leap-seconds.list
On 2025-04-24 07:04, Judah Levine wrote:
> Your comments have adequately addressed the #$ timetamp definition,
> which is described in the comments to the file. It has been defined this way
> for as long as I have prepared the file. There has been no leap second for a
> long time, and that time stamp reflects that fact. The name of the file is
> chosen in the same way - it changes only when a new leap event is announced,
> and now points to a time years ago.
> I choose the expiration date of the file so that the list of leap
> seconds in the file will be correct at least until that date. I use IERS
> Bulletin C, IERS Bulletin A, and other IERS data to derive that date. It
> includes a prediction of the evolution of UT1-UTC by the IERS, and is more
> comprehensive than the simple announcement of a leap second in Bulletin C.
> Apart from the recent and continuing drama in the environment here, the
> file has always been updated long before the expiration date arrives -
> usually when a new Bulletin C is published. The expiration date is intended
> to be a safety valve if (and only if) there are more serious problems. I
> regret that I cannot assure you that the current high level of drama is
> decreasing.
> The leap second file is distributed by FTP. The method has very
> significant difficulties - it is a long and tedious process to update the
> file, and there are various reports that it is difficult to access. I don't
> have a choice about this, at least for now. The other alternatives, such as a
> web page, would be even more difficult to maintain.
Thanks for the heads-up. This makes it clear that the NIST vs IERS
leap-seconds.list metadata differences are intentional. I installed the
attached proposed patch to TZDB to try to document this in a way that TZDB
users can easily understand.
If it weren't for the problems with FTP and with NIST's lagging expiration
timestamps, I'd prefer the NIST metadata as they're less volatile. For now,
though, the proposed patch merely changes commentary, rather than changing the
default leap-second data source from the IERS back to the NIST (which was the
source for many years, until TZDB release 2024a).
Perhaps after things have settled down we can help coordinate the IERS and NIST
leap-seconds.list files so that they agree not just about data, but also about
the last-modified and expiration timestamps. This would help reduce confusion
in the future.
