[tz] [PROPOSED] Merge timezones that are alike since 1970

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Jun 3 00:07:32 UTC 2021


On 2021-06-02 16:06, Paul Eggert via tz wrote:
> On 6/2/21 1:34 PM, Michael H Deckers via tz wrote:
>> On 2021-06-02 16:04, John Hawkinson wrote:
>>> Oh dear. My comment to Brian was not intended for the list, sorry!
>>> And doh! Yes, UTC of course.

Sent to MHD and me - no worries - nothing we can say you can't post.
>>      What I find surprising is that the days of the week
>>      as given by Brian are incorrect: the Gregorian dates
>>          -2147 481 748-01-01
>>          +2147 485 548-01-01
>>      are both Thursdays.

Shows what good decisions GNU and ISO made - both dates are ISO week 1.
That output's UTC from a script that does a binary search across the 64 
bit time_t space for the negative and positive limits which give a 
successful GNU date conversion, or set a file time using coreutils touch 
(and stat).
Now I think of it, that script should allow for the lower limit to be 
zero (as on Apple FS) not just negative.

> The incorrect output in Brian's email was likely due to a longstanding 
> signed integer overflow bug in tzcode, which I fixed on March 23:
> 
> https://mm.icann.org/pipermail/tz/2021-March/029968.html
> https://github.com/eggert/tz/commit/b73daeca66d395f6815466767139ae8b02cafde3 
> 
> Because of the bug, tzcode 'date -r' gave the wrong output for extreme 
> dates, such as the dates Brian used.
> 
> This fix should appear in the next tzdb release. Perhaps it's time for a 
> new release, as that bug has bothered me too.

I don't think that's a rush right now, as the values are so far out of 
any normally usable range, no one has yet complained, and most 
downstreams do not seem to directly use your code in libc. ;^<
And as soon as you issue one release, something will come up so you have 
to immediately release the next.
Kudos to those who thought of checking and noticed the bug!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]


More information about the tz mailing list