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.<br><br>On Monday, September 7, 2015, Tim Peters <<a href="mailto:tim.peters@gmail.com">tim.peters@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Guido]<br>
> ...<br>
>  (With the possible exceptions of the case where both zones are<br>
> known to be forever-fixed-offset, such as datetime.timezone instances and<br>
> pytz.utc, and even possibly the fixed-offset zones that pytz returns from<br>
> localize(). How exactly we're going to recognize those is a different<br>
> question, though I have an opinion there too.)<br>
<br>
BTW, I was looking at what it would take to do a 495-compliant<br>
wrapping of zoneinfo.  That essentially hands us .fromutc(), but<br>
leaves .utcoffset() a puzzle (mktime() all over again).<br>
<br>
I found what I thought was a very happy solution:  when loading the<br>
tzfile, it's easy to construct a list of every unique total UTC offset<br>
in the zone's history.  Order them from most recent to least, and then<br>
.utcoffset() would typically need to try no more than the first two to<br>
find one where .fromutc() reproduced .utcoffset()'s input.<br>
<br>
In that scheme, "is this a fixed offset zone?" is the same as asking<br>
whether the zone's unique-offsets list is a singleton.<br>
<br>
That doesn't belong in 495, just noting that the recognition question<br>
you raised is dead easy to answer for the most important source of<br>
timezone info.<br>
</blockquote><br><br>-- <br>--Guido van Rossum (on iPad)<br>