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.]