Date: Wed, 29 Nov 2023 11:28:00 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <2cfab05c-3580-4172-a412-525c43f75298@cs.ucla.edu> | 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. Sure, while we're distributing the leap seconds raw data, that should be complete (even if in a different format from the bulletin - distilling the info from many of them into one place), that's fine. Keeping the expiration date there isn't an issue - as long as the bulletins retain it. When (if) they stop publishing an expiration date (which probably means no more regular bulletins) then it should be removed from the files that are distributed with tzdata. | We haven't been getting reminders like this recently. I expect this is | because NTPD has declined in popularity. That, or that recently those files have been being regularly updated. If there's no need for a new tzdata distribution soon though, I think you might see requests again, as the ones currently in 2023c are due to expire in a little over a month. | Chrony then uses localtime and mktime to infer leap seconds. That's kind of bizarre, but whatever they feel is best. | 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. As long as it is getting it from the leap-seconds file (one of the variants) that's fine. | 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. Perhaps - though anything which fails to convert (as accurately as is believed possible) any time_t which can be represented in a struct tm wouldn't be POSIX conformant. Just stopping at some arbitrary time isn't permitted. Obviously everything about the future is just best guess. Whether users feel the need for updates or not (ideally of course, that would simply happen - at least for net connected systems) is ultimately their choice. | 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? If localtime() were really refusing to convert times, then who cares? If not, then there is no real expiration date in the file, just a lack of future data, for when it matters. kre