[PATCH] Don't mention boulder.nist.gov
The generated leapseconds file mentions the data can be retrieved from ftp.boulder.nist.gov/pub/time/leap-seconds.list, but the domain no longer resolves. From the Internet Archive for boulder.nist.gov it seems like it was a redirect for nist.gov until it was later deleted. The attached patch removes reference to it. Collin [1] https://web.archive.org/web/20180901000000*/boulder.nist.gov
On Fri, 18 Apr 2025 at 04:00, Collin Funk via tz <tz@iana.org> wrote:
The generated leapseconds file mentions the data can be retrieved from ftp.boulder.nist.gov/pub/time/leap-seconds.list, but the domain no longer resolves.
The domain definitely still resolves: $ dig ftp.boulder.nist.gov
<…snipped…> ;; ANSWER SECTION: ftp.boulder.nist.gov. 300 IN A 132.163.4.45 <…snipped…>
An ftp client can still connect to this server and the relevant file is still present: $ ftp ftp.boulder.nist.gov
Trying 132.163.4.45:21 ... Connected to ftp.boulder.nist.gov. 220 ProFTPD Server (NIST Time/Frequency Division FTP Server) [::ffff:10.88.0.2] Name (ftp.boulder.nist.gov:root): anonymous 331 Anonymous login ok, send your complete email address as your password Password: <…snipped…> 230 Anonymous access granted, restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp> ls pub/time/leap-seconds.list 229 Entering Extended Passive Mode (|||20091|) 150 Opening ASCII mode data connection for file list -rwxr-xr-x 1 ftp ftp 10921 Feb 7 2024 pub/time/leap-seconds.list 226 Transfer complete
Indeed, you can generally skip these steps by using something like `curl`: curl ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list >
leap-seconds-NIST.list
However, I note that the version of the file which is present on the NIST server is dated 2024-02-07 and has an expiration date of 2024-12-28. It's not clear whether this is just another temporary lapse on NIST's end or whether this points to a more recent deprecation of service of some sort. For what it's worth, other files on that server, namely in the wwvb directory, do appear to still be receiving (automated) updates. Perhaps part of the confusion here is that a URL with the ftp:// protocol can no longer be naïvely pasted into a modern web browser. As FTP usage declined steeply over the last decade or two, browsers have broadly dropped their once-native support for the FTP protocol. For example, Firefox 90 and Chrome 95 completely removed this functionality back in July and October 2021, respectively. In both cases, such functionality had even by that point already been deprecated, disabled-by-default, and on the chopping block for several years: https://blog.mozilla.org/security/2021/07/20/stopping-ftp-support-in-firefox... https://www.theregister.com/2021/07/21/firefox_ends_ftp_support/ https://developer.chrome.com/blog/deps-rems-95 https://www.theregister.com/2021/10/20/ftp_chrome_95/ We have many other FTP references throughout tzdata, so as long as useful data is still being served (which may indeed be an open question), it doesn't make any more sense to drop reference to this one than any of the others. -- Tim Parenti
On 2025-04-18 12:12 PM, Tim Parenti via tz wrote:
On Fri, 18 Apr 2025 at 04:00, Collin Funk via tz<tz@iana.org> wrote:
The generated leapseconds file mentions the data can be retrieved from ftp.boulder.nist.gov/pub/time/leap-seconds.list, but the domain no longer resolves.
The domain definitely still resolves:
$ digftp.boulder.nist.gov
<…snipped…> ;; ANSWER SECTION: ftp.boulder.nist.gov. 300 IN A 132.163.4.45 <…snipped…>
An ftp client can still connect to this server and the relevant file is still present:
$ ftpftp.boulder.nist.gov
Trying 132.163.4.45:21 ... Connected toftp.boulder.nist.gov. 220 ProFTPD Server (NIST Time/Frequency Division FTP Server) [::ffff:10.88.0.2] Name (ftp.boulder.nist.gov:root): anonymous 331 Anonymous login ok, send your complete email address as your password Password: <…snipped…> 230 Anonymous access granted, restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp> ls pub/time/leap-seconds.list 229 Entering Extended Passive Mode (|||20091|) 150 Opening ASCII mode data connection for file list -rwxr-xr-x 1 ftp ftp 10921 Feb 7 2024 pub/time/leap-seconds.list 226 Transfer complete
Indeed, you can generally skip these steps by using something like `curl`:
curlftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list >
leap-seconds-NIST.list
However, I note that the version of the file which is present on the NIST server is dated 2024-02-07 and has an expiration date of 2024-12-28. It's not clear whether this is just another temporary lapse on NIST's end or whether this points to a more recent deprecation of service of some sort. For what it's worth, other files on that server, namely in the wwvb directory, do appear to still be receiving (automated) updates.
Perhaps part of the confusion here is that a URL with the ftp:// protocol can no longer be naïvely pasted into a modern web browser. As FTP usage declined steeply over the last decade or two, browsers have broadly dropped their once-native support for the FTP protocol. For example, Firefox 90 and Chrome 95 completely removed this functionality back in July and October 2021, respectively. In both cases, such functionality had even by that point already been deprecated, disabled-by-default, and on the chopping block for several years: https://blog.mozilla.org/security/2021/07/20/stopping-ftp-support-in-firefox... https://www.theregister.com/2021/07/21/firefox_ends_ftp_support/ https://developer.chrome.com/blog/deps-rems-95 https://www.theregister.com/2021/10/20/ftp_chrome_95/
We have many other FTP references throughout tzdata, so as long as useful data is still being served (which may indeed be an open question), it doesn't make any more sense to drop reference to this one than any of the others.
-- Tim Parenti
I can read ftp.boulder.nist.gov/pub/time/leap-seconds.list with an FTP client app. As you say that version says: # Updated through IERS Bulletin C67 # File expires on: 28 December 2024 But note what you find at IANA: https://data.iana.org/time-zones/data/leap-seconds.list which says: Updated through IERS Bulletin C (https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat) File expires on 28 December 2025 So seems somebody updated that one from some other source? Such as: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list This matches the file at IANA.
On Fri, 18 Apr 2025 at 12:58, Brooks Harris via tz <tz@iana.org> wrote:
So seems somebody updated that one from some other source? Such as: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
Yes, tzdata started preferring and pulling directly from IERS in 2024, because (a) NIST was becoming increasingly slow at updating their version, (b) the previously-unclear copyright status of using IERS' files directly was finally resolved, and (c) IERS is the decision-making body for leap seconds, so it makes sense to get it straight from the source. -- Tim Parenti
On 2025-04-18 01:08 PM, Tim Parenti wrote:
On Fri, 18 Apr 2025 at 12:58, Brooks Harris via tz<tz@iana.org> wrote:
So seems somebody updated that one from some other source? Such as: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
Yes, tzdata started preferring and pulling directly from IERS in 2024, because (a) NIST was becoming increasingly slow at updating their version, (b) the previously-unclear copyright status of using IERS' files directly was finally resolved, I remember reading about that on the list. and (c) IERS is the decision-making body for leap seconds, so it makes sense to get it straight from the source. So this should be made clear to developers and users in the docs somewhere, right? Thanks.
-- Tim Parenti
Hi Tim, Tim Parenti <tim@timtimeonline.com> writes:
The domain definitely still resolves: [...] An ftp client can still connect to this server and the relevant file is still present:
Yes, I see it now. Must have been network issues, or more likely user error, which made me think it was dead. Sorry for the noise. Collin
On 2025-04-18 10:12, Tim Parenti via tz wrote:
On Fri, 18 Apr 2025 at 04:00, Collin Funk via tz <tz@iana.org <mailto:tz@iana.org>> wrote:
The generated leapseconds file mentions the data can be retrieved from ftp.boulder.nist.gov/pub/time/leap-seconds.list <http:// ftp.boulder.nist.gov/pub/time/leap-seconds.list>, but the domain no longer resolves.
The domain definitely still resolves:
$ dig ftp.boulder.nist.gov <http://ftp.boulder.nist.gov> <…snipped…> ;; ANSWER SECTION: ftp.boulder.nist.gov <http://ftp.boulder.nist.gov>. 300 IN A 132.163.4.45 <…snipped…>
An ftp client can still connect to this server and the relevant file is still present:
$ ftp ftp.boulder.nist.gov <http://ftp.boulder.nist.gov> Trying 132.163.4.45:21 <http://132.163.4.45:21> ... Connected to ftp.boulder.nist.gov <http://ftp.boulder.nist.gov>. 220 ProFTPD Server (NIST Time/Frequency Division FTP Server) [::ffff:10.88.0.2] Name (ftp.boulder.nist.gov:root): anonymous 331 Anonymous login ok, send your complete email address as your password Password: <…snipped…> 230 Anonymous access granted, restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp> ls pub/time/leap-seconds.list 229 Entering Extended Passive Mode (|||20091|) 150 Opening ASCII mode data connection for file list -rwxr-xr-x 1 ftp ftp 10921 Feb 7 2024 pub/time/leap- seconds.list 226 Transfer complete
Indeed, you can generally skip these steps by using something like `curl`:
curl ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list <ftp:// ftp.boulder.nist.gov/pub/time/leap-seconds.list> > leap-seconds-NIST.list
However, I note that the version of the file which is present on the NIST server is dated 2024-02-07 and has an expiration date of 2024-12-28. It's not clear whether this is just another temporary lapse on NIST's end or whether this points to a more recent deprecation of service of some sort. For what it's worth, other files on that server, namely in the wwvb directory, do appear to still be receiving (automated) updates.
Perhaps part of the confusion here is that a URL with the ftp:// protocol can no longer be naïvely pasted into a modern web browser. As FTP usage declined steeply over the last decade or two, browsers have broadly dropped their once- native support for the FTP protocol. For example, Firefox 90 and Chrome 95 completely removed this functionality back in July and October 2021, respectively. In both cases, such functionality had even by that point already been deprecated, disabled-by-default, and on the chopping block for several years: https://blog.mozilla.org/security/2021/07/20/stopping-ftp-support-in-firefox... <https://blog.mozilla.org/security/2021/07/20/stopping-ftp-support-in-firefox...> https://www.theregister.com/2021/07/21/firefox_ends_ftp_support/ <https:// www.theregister.com/2021/07/21/firefox_ends_ftp_support/> https://developer.chrome.com/blog/deps-rems-95 <https://developer.chrome.com/ blog/deps-rems-95> https://www.theregister.com/2021/10/20/ftp_chrome_95/ <https:// www.theregister.com/2021/10/20/ftp_chrome_95/>
We have many other FTP references throughout tzdata, so as long as useful data is still being served (which may indeed be an open question), it doesn't make any more sense to drop reference to this one than any of the others.
Note that it appears that Boulder is now the only source for NIST T&F FTP data: https://www.nist.gov/pml/time-and-frequency-division/time-distribution/inter... Links to current bulletins and some other data archives are available at: https://www.nist.gov/pml/time-and-frequency-division/time-realization/time-s... It still looks as if there will be no decision on leap seconds until 2035, and DUT1 keeps heading towards zero in different directions, but some are thinking we might need a *negative* leap second before then? [With the way things are going, and evidence pointing to policy being developed based on LLM outputs, fed by opinions on social media, it seems possible that atomic time keeping, or all NIST, could be defunded in the US!] -- 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
Tim Parenti via tz wrote:
On Fri, 18 Apr 2025 at 04:00, Collin Funk via tz <tz@iana.org <mailto:tz@iana.org>> wrote:
The generated leapseconds file mentions the data can be retrieved from ftp.boulder.nist.gov/pub/time/leap-seconds.list <http:// ftp.boulder.nist.gov/pub/time/leap-seconds.list>, but the domain no longer resolves.
The domain definitely still resolves:
$ dig ftp.boulder.nist.gov <http://ftp.boulder.nist.gov> <…snipped…> ;; ANSWER SECTION: ftp.boulder.nist.gov <http://ftp.boulder.nist.gov>. 300 IN A 132.163.4.45 <…snipped…>
An ftp client can still connect to this server and the relevant file is still present:
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. Martin -- Martin Burnicki Senior Software Engineer Email: martin.burnicki@meinberg.de 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 100322 Managing Directors: Natalie Meinberg, Daniel Boldt, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Meinberg - The Synchronization Experts.
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.
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... 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. Martin -- Martin Burnicki Senior Software Engineer Email: martin.burnicki@meinberg.de 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 100322 Managing Directors: Natalie Meinberg, Daniel Boldt, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Meinberg - The Synchronization Experts.
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
Brian Inglis via tz wrote:
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:
Yes, that happened when the IERS folks started providing a leap second file, but it's been going smoothly now for some years.
$ 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,
Yes, presuming, but that's not authoritative right now.
... 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).
That's also how I understand it. See also my next reply to Tim. Martin -- Martin Burnicki Senior Software Engineer Email: martin.burnicki@meinberg.de 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 100322 Managing Directors: Natalie Meinberg, Daniel Boldt, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Meinberg - The Synchronization Experts.
On Wed, 23 Apr 2025 at 05:30, Martin Burnicki via tz <tz@iana.org> 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 <tz@iana.org> 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
Tim Parenti wrote:
On Wed, 23 Apr 2025 at 05:30, Martin Burnicki via tz <tz@iana.org <mailto:tz@iana.org>> 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 <tz@iana.org <mailto:tz@iana.org>> 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: martin.burnicki@meinberg.de 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 100322 Managing Directors: Natalie Meinberg, Daniel Boldt, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Meinberg - The Synchronization Experts.
participants (6)
-
Brian Inglis -
Brooks Harris -
Collin Funk -
Martin Burnicki -
Paul Eggert -
Tim Parenti