On 2025-04-23 03:30, Martin Burnicki via tz wrote:
Paul Eggert wrote:
On 2025-04-22 00:28, Martin Burnicki via tz wrote:
Right now I can also access this FTP server here from Germany.
In the past I was often unable to do that, and sometimes I was unable to
access it here from Germany, but succeeded when I tried from a remote server
located in the U.S., which seems to indicate that there was a firewall/geo-
blocking problem.
Anyway, to me it looks like the IERS service is nowadays much more reliable.
I wrote to NIST about this, and <ftp://ftp.boulder.nist.gov/pub/time/ leap-
seconds.list> was updated yesterday. Indeed it now has an expiration date of
June 2026 instead of the December 2025 expiration date of IERS's copy of the
file.
Although NIST's longer expiration date would be better for TZDB, I'm inclined
to leave things along for now. That is, TZDB can continue to source leap-
seconds.list from the IERS while listing NIST as an alternative source. This
is partly due to the longstanding server connection hassles at NIST, and
partly due to my hopefully- understandable inertia.
Hm, as far as I can see, the new NIST file has some drawbacks.
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.
This timestamp was also commonly used for the extension to the name of the
original file, and "leap-second.list" was a symbolic link to latest/current
version of these files.
The name of the original current leap second file from IERS is "leap-
seconds.3945196800" and it contains the following lines:
# The following line shows the last update of this file in NTP timestamp:
#
#$ 3945196800
where "3945196800" means "2025-01-07 00:00:00", i.e., the time when the file was
published together with the latest/current bulletin C 69.
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.
Similarly, the expiration time in the NIST file makes no sense to me. Even
though that actually it's not very likely that another leap second event will
happen, let's have a closer look:
- The last bulletin C was released in January 2025, telling that *NO* leap
second will occur at the end of June 2025.
- The next bulletin C will be released in July 2025, telling *whether* a leap
second will or will not occur at the end of December 2025.
So in any case we can be sure that no leap second will occur before December 31,
2025, and it is absolutely safe that a leap second file published after bulletin
C in January 2025 is valid for nearly 12 months, but not any longer.
It means that users have nearly 6 months time to update their copy of the leap
second file after the next one will have been published in July 2025.
This was already discussed here on the list, and I've explained this many times
to customers, so I also added this information to a knowledge base article about
the leap second file:
https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/
ntp_leap_second_file#expiration_date
In my opinion it is confusing and error prone to define an expiration date of
June 2026 for a file that was last updated from a bulletin C published in
January 2025. Imagine that (even unexpectedly) the next bulletin C will announce
a leap second for December 31, 2025. In this case users of the IERS file will
know that their old file expires and take care to update the file, which will
contain this information.
However, users of the NIST file might assume that no update is necessary before
the end of June 2026, and therefore miss the leap second at the end of December
2025.
As mentioned earlier, I'm aware that it's very unlikely that a leap second event
will happen in the near future, but I'd always prefer reliability over assumptions.
I have my own leap-seconds.* hash, updated, and expiry date checker/extractor as
IERS did not always get the data correct either, with latest IERS and NIST values:
$ leapsec-sha.sh /etc/leap-seconds.list
leapsec-sha.sh:/etc/leap-seconds.list:modified 2025-01-07 expires 2025-12-28 #
File expires on 28 December 2025
$ leapsec-sha.sh leap-seconds.3676924800
leapsec-sha.sh:leap-seconds.3676924800:modified 2016-07-08 expires 2026-06-28 #
File expires on: 28 June 2026
so NIST expiry is correct presuming no leap second is announced in the upcoming
July Bulletin C #70, but the overall file format, update date, and NTP time
suffix are defined in the ntp-keygen(1) section "Cryptographic Data Files", such
that the date and suffix should be that of the file creation (as a new file
should be created with a new suffix for each update).
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
