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