The TZDB mailing list has recently been wrestling with the topic of
leap-second table expiration (see [1] and [2] for some of this).
Here's the issue. The leap-seconds.list file, maintained by Judah Levine
of NIST and redistributed by TZDB, contains a line like this:
#@ 3928521600
which in this example specifies an expiration date of 2024-06-28 00:00
UTC. The idea is that this particular leap-seconds.list file should not
be used after the expiration date, after which the file will be obsolete
and pehaps incorrect.
As I understand it, NTPsec parses this comment and rejects obsolete
leap-seconds.list files; this is the traditional ntpd behavior.
Currently Chrony does not look at the leap-seconds.list file. However,
yesterday Patrick Oppenlander proposed[3] a patch to do that.
So, three questions:
* If Chrony reads leap-seconds.list should it also look at the leap
second expiration and reject old files?
* If Chrony does not read leap-seconds.list, but instead uses the
right/UTC file, should it also look at any leap-second expiration
information in that file and reject old files? This would involve Chrony
looking at the file directly instead of relying on localtime/mktime, and
building right/UTC with TZDB's EXPIRES_LINE=1 option.
* If leap seconds are discontinued, which is a distinct possibility,
what sort of "leap second expiration" should Chrony use?
[1]: https://mm.icann.org/pipermail/tz/2023-November/033268.html
[2]: https://mm.icann.org/pipermail/tz/2023-November/033275.html
[3]:
https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-dev/2023/11/msg00013.html
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
