On 2024-07-29 16:20, Tim Parenti via tz wrote:

No leap second 2024-12-31, per below. See attached patch.

Thanks. While we're on the topic of leap seconds, Judah Levine's proposal to replace leap seconds was published this month as a preprint by Metrologia. Although the paper is supposed to be public domain in the US (because it's a product of the federal government), Metrologia doesn't make it freely readable, which is not quite cricket; thankfully a preprint is publicly available. Levine's proposal would replace leap seconds with leap smears every decade. Until 2100 the smears would adjust clocks by 13 seconds. After 2100 the "13" could be adjusted upward as needed. The idea is to keep UTC to within 100-or-so seconds of UT1, by adjusting via a smear once per decade, and to do this adjustment algorithmically (i.e., without paying attention to what the Earth actually does) so as to make TAI-UTC more predictable. Using a leap smear would keep TAI-UTC continuous over time. Levine suggests running UTC clocks half-speed during the smear; this means TAI-UTC would be continuous but not continuously differentiable. My back-of-the-envelope calculations suggest that this scheme would work for about half a millennium before accumulated tidal friction would necessitate further adjustment or replacement. If I understand things correctly, Levine would rather get out of the leap-second-table publishing business, and so would rather have the leap smear implemented directly via code in localtime.c (or whatever), instead of being disseminated by a table that needs updating every six months. Presumably a new version of the code would need to be disseminated before the year 2100 rolls around. If we resisted this hint and used a table anyway, the table would have one entry per century and would stop working after five entries or so; not sure it'd worth the effort to implement it that way. Proposed documentation patch attached and installed in the development sources.