[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. _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
