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.
From cd85cc1b9fdde604087c258787179cabfa86268f Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email protected]>
Date: Thu, 24 Apr 2025 12:24:22 -0700
Subject: [PROPOSED] Document IERS vs NIST leap second metadata

* Makefile, NEWS: Mention this.
* leapseconds.awk: Output comments explaining the difference
between the IERS and NIST leap-seconds.list last-modified
and expiration metadata.  (Thanks to Judah Levine.)
---
 Makefile        |  5 +++++
 NEWS            |  6 ++++++
 leapseconds.awk | 11 +++++++++--
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 42f5135f..99407112 100644
--- a/Makefile
+++ b/Makefile
@@ -464,6 +464,11 @@ leaplist_URI = \
   https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
 # The file is generated by the IERS Earth Orientation Centre, in Paris.
 leaplist_TZ = Europe/Paris
+#
+# To fetch leap-seconds.list from NIST via a less-secure protocol
+# and with less-volatile metadata, use these settings:
+#leaplist_URI = ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list
+#leaplist_TZ = America/Denver
 
 # The zic command and its arguments.
 
diff --git a/NEWS b/NEWS
index 7a05aeb9..779b654e 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,12 @@ Unreleased, experimental changes
     reproducible timestamps.  Formerly, only the contents of the
     compressed tarballs had reproducible timestamps.
 
+  Changes to commentary
+
+    The leapseconds file contains commentary about the IERS and NIST
+    last-modified and expiration timestamps for leap second data.
+    (Thanks to Judah Levine.)
+
 
 Release 2025b - 2025-03-22 13:40:46 -0700
 
diff --git a/leapseconds.awk b/leapseconds.awk
index 15e85012..b9986164 100644
--- a/leapseconds.awk
+++ b/leapseconds.awk
@@ -23,7 +23,8 @@ BEGIN {
   print "# This file is generated automatically from the data in the public-domain"
   print "# NIST/IERS format leap-seconds.list file, which can be copied from"
   print "# <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>"
-  print "# or, in a variant with different comments, from"
+  print "# or via a less-secure protocol and with different comments and"
+  print "# less volatile last-modified and expiration timestamps, from"
   print "# <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>."
   print "# For more about leap-seconds.list, please see"
   print "# The NTP Timescale and Leap Seconds"
@@ -125,7 +126,13 @@ END {
     epoch_minus_NTP = ((1970 - 1900) * 365 + 17) * 24 * 60 * 60
 
     print ""
-    print "# POSIX timestamps for the data in this file:"
+    print "# Here are POSIX timestamps for the data in this file."
+    print "# \"#updated\" gives the last time the leap seconds data changed"
+    print "# or, if this file was derived from the IERS leap-seconds.list,"
+    print "# the last time that file changed in any way."
+    print "# \"#expires\" gives the first time this file might be wrong;"
+    print "# if this file was derived from the IERS leap-seconds.list,"
+    print "# this is typically a bit less than one year after \"updated\"."
     if (updated) {
       sstamp_to_ymdhMs(updated, ss_NTP)
       printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \
-- 
2.48.1

Reply via email to