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

[Brian Inglis]

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