<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 12, 2015 at 10:25 PM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I will try to create a  zoneinfo wrapping prototype as well, but I will<br>
> probably "cheat" and build it on top of pytz.<br>
<br>
</span>It would be crazy not to ;-)  Note that Stuart got to punt on "the<br>
hard part":  .utcoffset(), since pytz only uses fixed-offset classes.<br>
For a prototype - and possibly forever after - I'd be inclined to<br>
create an exhaustive list of transition times in local time, parallel<br>
to the list of such times already there in UTC.</blockquote><div><br></div><div>Yes.  The only complication is that you need four transition points instead of two per year in a regular DST case: (1) start of gap; (2) end of gap; (3) start of fold; and (4) end of fold.  Once you know where you are with respect to those points, figuring out utcoffset(), dst() and tzname() for either value of fold is trivial. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  An index into either<br>
list then gives an index into the other, and into the list of<br>
information about the transition (total offset, is_dst, etc).</blockquote></div><br>Right.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It's a shame though to work from a transitions in UTC list because most of DST rules are expressed in local times and then laboriously converted into UTC.  I think I should also implement the POSIX TZ spec tzinfo.  This is where the advantage of the "as intended" approach will be obvious. </div></div>