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: # #$ 3945196800where "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_dateIn 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.
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
