On 3/12/21 9:58 AM, Paul Eggert wrote:
On 3/12/21 1:55 AM, Ian Abbott wrote:
For (B), would adding an extra leap-second record at the expiry time with no difference in correction value work? That would not conform to RFC 8536, but seems unlikely to break any thing unless that thing is strictly checking that correction values differ by exactly 1.
Exactly my thought. Unfortunately tzcode itself is picky here (because I mistakenly made it picky when helping to write RFC 8536). I doubt whether anyone else is so picky unless they're imitating tzcode itself. That being said, we'll need to be a bit cautious here, and not introduce this change willy-nilly.
After thinking about it a bit I installed the following patches to implement the above suggestions: https://mm.icann.org/pipermail/tz/2021-March/029934.html https://mm.icann.org/pipermail/tz/2021-March/029940.html Since the affected TZif files do not conform to Internet RFC 8536 it appears we'll need a new TZif version number, version 4, to mark files with this new feature. This new version number will appear only on the problematic files that are generated with leapsecond data that contains an explicit "Expires" line, and such data will not be generated by default. The idea is that TZif version 4 will be documented in an amended version of RFC 8536. Comments welcome as usual.