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-ke...>), 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.