On Tue, 16 Mar 2021, Paul Eggert via tz wrote:
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.
How would I be able to generate such a TZif4 file, so that I can test whether timelib can read them correctly? FWIW, timelib doesn't support leapseconds for calculations, but I do need to know whether I can read the files. cheers, Derick -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug