[Datetime-SIG] IANA TZ database statistics

Alexander Belopolsky alexander.belopolsky at gmail.com
Thu Sep 24 05:58:18 CEST 2015


> [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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150923/36ce55cd/attachment-0001.html>


More information about the Datetime-SIG mailing list