[Datetime-SIG] PEP 495: What's left to resolve

Guido van Rossum guido at python.org
Tue Sep 8 07:44:24 CEST 2015

No, the question I care about is more like "could politicians change the
utc offset", not whether they have done so in the past. So instances of
datetime.timezone qualify, as do (I believe) lettered "military" zone names.

On Monday, September 7, 2015, Tim Peters <tim.peters at gmail.com> wrote:

> [Guido]
> > ...
> >  (With the possible exceptions of the case where both zones are
> > known to be forever-fixed-offset, such as datetime.timezone instances and
> > pytz.utc, and even possibly the fixed-offset zones that pytz returns from
> > localize(). How exactly we're going to recognize those is a different
> > question, though I have an opinion there too.)
> BTW, I was looking at what it would take to do a 495-compliant
> wrapping of zoneinfo.  That essentially hands us .fromutc(), but
> leaves .utcoffset() a puzzle (mktime() all over again).
> I found what I thought was a very happy solution:  when loading the
> tzfile, it's easy to construct a list of every unique total UTC offset
> in the zone's history.  Order them from most recent to least, and then
> .utcoffset() would typically need to try no more than the first two to
> find one where .fromutc() reproduced .utcoffset()'s input.
> In that scheme, "is this a fixed offset zone?" is the same as asking
> whether the zone's unique-offsets list is a singleton.
> That doesn't belong in 495, just noting that the recognition question
> you raised is dead easy to answer for the most important source of
> timezone info.

--Guido van Rossum (on iPad)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150907/e13a5deb/attachment-0001.html>

More information about the Datetime-SIG mailing list