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

[Tim Peters]

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