> [Alex] > > My code ignores "version 2" data, so I include only transitions > > that fall within 32-bit time_t (1900 to 2038 range). > [Tim] > From staring at zic.c,
.. I get a pounding headache. :-( > looks like (so far) the data in the version 2 > section is identical to that in the version 1 section, except written > out in wider data formats. The pretty clear intent is that they never > intend to generate explicit transitions beyond 2037 in any version, > I compiled the latest Github version on my Mac and I get $ /usr/local/etc/zdump -V 'America/New_York'| tail -4 America/New_York Sun Mar 8 06:59:59 2499 UT = Sun Mar 8 01:59:59 2499 EST isdst=0 gmtoff=-18000 America/New_York Sun Mar 8 07:00:00 2499 UT = Sun Mar 8 03:00:00 2499 EDT isdst=1 gmtoff=-14400 America/New_York Sun Nov 1 05:59:59 2499 UT = Sun Nov 1 01:59:59 2499 EDT isdst=1 gmtoff=-14400 America/New_York Sun Nov 1 06:00:00 2499 UT = Sun Nov 1 01:00:00 2499 EST isdst=0 gmtoff=-18000 > until it's after 2037 in the real world and they need to do so because > a POSIX TZ rule can't handle some new goofy exception (and version 2 > also contains a POSIX TZ rule at the end, when possible). What they do is a so-called 400-year hack: since the Gregorian calendar repeats itself every 400 years, any regular calendar-based rule will generate transitions with a 400-year period. This observation allows them to generate 400+ years of explicit transitions through 2499 and extent that through eternity by periodicity. > Then they'll need to add new transitions in the version 2 section only > (version 1 data formats are too narrow to record them). > > They already do that for transitions both before EPOCH - 2**31 seconds and after EPOCH + 2**31 seconds. $ /usr/local/etc/zdump -V 'America/New_York'| head -2 America/New_York Sun Nov 18 16:59:59 1883 UT = Sun Nov 18 12:03:57 1883 LMT isdst=0 gmtoff=-17762 America/New_York Sun Nov 18 17:00:00 1883 UT = Sun Nov 18 12:00:00 1883 EST isdst=0 gmtoff=-18000 [Alex] > I am considering making the cut-off at 1970 and assume 1970 standard > time for all times before that year. > [Tim] > Is there a real need for a "high performance" tzinfo? This is not about new tzinfos. This is about implementing PEP 495's .astimezone(). > That is, who cares? ;-) I do. :-) > It would sure be _surprising_ if a Python wrapping of > zoneinfo returned different results than native Linux tools wrapping > the same thing. > This is not about wrapping IANA's tzdist. This is about implementing PEP 495 features using POSIX APIs. > [Alex] > I think this is best we can do on Windows > [Tim] > Of course not, if by "best" we mean "gets the same answers everyone > else gets". In that case, "best" is returning what the IANA database > says should be returned in all cases. > Which version of IANA database? > [Alex] > where (IIRC) mktime does not work for times before epoch. (What about > > localtime?) > [Tim] > >>> time.localtime(-1) .. OSError: [Errno 22] Invalid argument > That's what I thought. > > Which is another meaning for "best": avoid flaky C library functions > altogether. > > >>> time.localtime(1e11) .. > OSError: [Errno 22] Invalid argument > I don't want to try to figure out how to access tzfiles in a portable way. We need another PEP for this because I don't see any better solution than to repackage IANA files as a pip-installable package. Such PEP should probably be discussed on distutils-sig first.
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
