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

[Paul Eggert]

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/>.

Chrony does not currently read leap-seconds.list directly; instead, it 
gets leap second information by setting TZ="right/UTC", which causes 
most Linux implementations to consult /usr/share/zoneinfo/right/UTC, 
which is a TZif file with leap seconds. Chrony then uses localtime and 
mktime to infer leap seconds. Because localtime/mktime ignore leap 
second expiry, Chrony cannot deduce the leap second expiration time of 
the TZif file even if the TZif file contains this info.

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.

Internet RFC 8536 specifies a provision for truncating TZif files so 
that timestamps after time T are not supported; this is partly to save 
space when transmitting them, and partly I assume for the same reason 
that leap-seconds.list has an expiration date - some TZif distributors 
want to ensure their users get periodic updates. However, after RFC 8536 
came out we discovered that this truncation provision in some sense 
collides with leap second expiry: should a truncated table mean that 
leap seconds expire too? or vice versa? That sort of thing. This is 
partly why I asked the question.

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.