[tz] If leap seconds go away, should TZif leap-second tables expire?

Brian Inglis Brian.Inglis at Shaw.ca
Wed Nov 29 22:35:10 UTC 2023

On 2023-11-29 12:28, Paul Eggert via tz wrote:
> On 2023-11-29 01:16, Robert Elz wrote:
>> What do you believe this field in the TZif files is useful for now?
> I don't use leap second expiry myself, so I'm not the best person to ask - which 
> is why I posted the question. However, here's a brief summary of what I know.
> As you may recall, a few years ago the tz list was periodically asked by 
> downstream users to update the leap-seconds.list file, even when that file's 
> list of leap seconds did not change. This was because leap-seconds.list contains 
> a special comment line like "#@ 3928521600" containing an expiration time, and 
> NTPD rejects a leap-seconds.list file with expiration time in the past. See, for 
> example, Martin Burnicki's 2015 email here:
> https://mm.icann.org/pipermail/tz/2015-December/023032.html
> We haven't been getting reminders like this recently. I expect this is because 
> NTPD has declined in popularity. Although the original NTPD is no longer 
> maintained (see Nate Hopper's New Yorker piece a year ago 
> <https://www.newyorker.com/tech/annals-of-technology/the-thorny-problem-of-keeping-the-internets-time>), NTPsec <https://www.ntpsec.org/> is still alive and kicking and I think it still reads leap-seconds.list and looks at the expiration. However, I think many systems that formerly would have used NTPD are now using Chrony <https://chrony-project.org/>.

> Coincidentally, yesterday Patrick Oppenlander proposed adding a 
> leap-seconds.list parser to Chrony 
> <https://www.mail-archive.com/chrony-dev@chrony.tuxfamily.org/msg02696.html>. 
> Although Oppenlander's patch does not support leap second expiry, it might be 
> just a matter of time before it adds support for that too.

> Given the above, I plan to ask the chrony folks about this issue. If they don't 
> care about leap second expiry in TZif files it's likely nobody else cares either.

The leap-seconds.list expiration date specifies the limit of when the current 
delta TAI-UTC and stepless UTC period is *KNOWN* to be valid, for those systems 
and processes which rely on knowing some time scale with certainty and accuracy 
within a fraction of a second (NTP < 128ms, normally ~ 1us).
After the expiration date, the uncertainty is >1s!

IERS now reports and updates this consistently and correctly and specifies 
{Jun,Dec}-28 following the next leap second update effective date e.g. Bulletin 
C 66 2023-07-04 00:00Z NTP 3897417600 announces no leap second 2023-12-31 24:00Z 
NTP 3913081200 and that is valid until 2024-06-24 00:00Z NTP 3928521600 and 
those values are specified in leap-seconds.list.

There have been times since 2017 when NIST has not published updates soon enough 
and time keepers have made their own, or switched to IERS which is definitive.

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 à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

More information about the tz mailing list