<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">[Alex]<br>
<span class="">> My code ignores "version 2" data, so I include only transitions<br>
> that fall within 32-bit time_t (1900 to 2038 range).<br>
[Tim]<br>
</span>From staring at zic.c,</blockquote><div><br></div><div>.. I get a pounding headache. :-(</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> looks like (so far) the data in the version 2<br>
section is identical to that in the version 1 section, except written<br>
out in wider data formats.  The pretty clear intent is that they never<br>
intend to generate explicit transitions beyond 2037 in any version,<br></blockquote><div><br></div><div>I compiled the latest Github version on my Mac and I get</div><div><br></div><div><div><font size="1" face="monospace, monospace">$ /usr/local/etc/zdump -V 'America/New_York'| tail -4</font></div><div><font size="1" face="monospace, monospace">America/New_York  Sun Mar  8 06:59:59 2499 UT = Sun Mar  8 01:59:59 2499 EST isdst=0 gmtoff=-18000</font></div><div><font size="1" face="monospace, monospace">America/New_York  Sun Mar  8 07:00:00 2499 UT = Sun Mar  8 03:00:00 2499 EDT isdst=1 gmtoff=-14400</font></div><div><font size="1" face="monospace, monospace">America/New_York  Sun Nov  1 05:59:59 2499 UT = Sun Nov  1 01:59:59 2499 EDT isdst=1 gmtoff=-14400</font></div><div><font size="1" face="monospace, monospace">America/New_York  Sun Nov  1 06:00:00 2499 UT = Sun Nov  1 01:00:00 2499 EST isdst=0 gmtoff=-18000</font></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
until it's after 2037 in the real world and they need to do so because<br>
a POSIX TZ rule can't handle some new goofy exception (and version 2<br>
also contains a POSIX TZ rule at the end, when possible).</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  Then they'll need to add new transitions in the version 2 section only<br>
(version 1 data formats are too narrow to record them).<br><span class=""><br></span></blockquote><div>They already do that for transitions both before EPOCH - 2**31 seconds and after EPOCH + 2**31 seconds.</div><div><font size="1" face="monospace, monospace"><br></font></div><div><div><font size="1" face="monospace, monospace">$ /usr/local/etc/zdump -V 'America/New_York'| head -2</font></div><div><font size="1" face="monospace, monospace">America/New_York  Sun Nov 18 16:59:59 1883 UT = Sun Nov 18 12:03:57 1883 LMT isdst=0 gmtoff=-17762</font></div><div><font size="1" face="monospace, monospace">America/New_York  Sun Nov 18 17:00:00 1883 UT = Sun Nov 18 12:00:00 1883 EST isdst=0 gmtoff=-18000</font></div></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">[Alex] </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> I am considering making the cut-off at 1970 and assume 1970 standard</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> time for all times before that year.<br>
[Tim]<br>
</span>Is there a real need for a "high performance" tzinfo?</blockquote><div><br></div><div>This is not about new tzinfos.  This is about implementing PEP 495's .astimezone().</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  That is, who cares? ;-) </blockquote><div><br></div><div>I do.  :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> It would sure be _surprising_ if a Python wrapping of<br>
zoneinfo returned different results than native Linux tools wrapping<br>
the same thing.<br></blockquote><div><br></div><div>This is not about wrapping IANA's tzdist.  This is about implementing PEP 495 features using POSIX APIs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">[Alex]</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">>  I think this is best we can do on Windows<br>
[Tim]<br>
</span>Of course not, if by "best" we mean "gets the same answers everyone<br>
else gets".  In that case, "best" is returning what the IANA database<br>
says should be returned in all cases.<br></blockquote><div><br></div><div>Which version of  IANA database?  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">[Alex]</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> where (IIRC) mktime does not work for times before epoch.  (What about<br>
> localtime?)</span><br>
[Tim]<br>
>>> time.localtime(-1) .. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
OSError: [Errno 22] Invalid argument<br></blockquote><div><br></div><div>That's what I thought.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Which is another meaning for "best":  avoid flaky C library functions<br>
altogether.<br><br>
>>> time.localtime(1e11) ..<br>
OSError: [Errno 22] Invalid argument<br>
</blockquote></div><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div></div>