On 07/03/2021 02:07, Paul Eggert wrote:
For clients using TZif files with leap second support, we have three objectives:
A. Fix and/or work around the longstanding localtime.c bug.
B. Clients should be able to deduce when the leap second table expires.
C. Clients should be able to predict timestamps after the expiration date more accurately than just "assume the latest-known UTC offset".
The second change supported (A) and (B), but broke (C).
Given the problems you described, I installed the attached patch, which omits the truncation introduced in tzdb 2020a. This fixes (C), but breaks both (A) and (B). I'll try to think of a better way to support (A) and (B).
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. -- -=( Ian Abbott <abbotti@mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-