<div dir="ltr"><br><br>On Wed, Apr 15, 2015 at 5:28 PM, Stuart Bishop <<a href="mailto:stuart@stuartbishop.net">stuart@stuartbishop.net</a>> wrote:<br>><br>> On 15 April 2015 at 21:51, Lennart Regebro <<a href="mailto:regebro@gmail.com">regebro@gmail.com</a>> wrote:<br>> > On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop <<a href="mailto:stuart@stuartbishop.net">stuart@stuartbishop.net</a>> wrote:<br>><br>> > Just punting it to tzinfo to make adjustments, ie effectively just<br>> > doing what normalize() does creates infinite recursion as there is<br>> > more arithmetic in there, so it's not quite that simple.<br>><br>> This sounds familiar. Its infinite recursion if the tzinfo does its<br>> calculations using localized datetimes. If the tzinfo is stripped for<br>> the calculations, there is no tzinfo to recurse into. At least this<br>> was how I hoped it would work, and it sucks if it doesn't. You could<br>> be right that using the UTC representation internally for datetimes<br>> with a tzinfo makes the most sense.<br><br>There is no infinite recursion in the way datetime module deals with zone conversions.   However, implementors of tzinfo subclasses often overlook the fact that datetime module design mandates specific rules for what utcoffset() should return for the missing and ambiguous hours. Granted, the relevant section in the manual [1] is not an easy read and in fact for a long time that documentation itself was displaying a buggy implementation of the LocalTimezone class. [2]<div><br></div><div>Understanding how the design works requires a bit of algebra [3], but I strongly recommend that anyone trying to improve the timezones support in the datetime module, print out those 200 lines of comments and go through them with a pencil following the proofs.</div><div><br></div><div>Note that one of the key assumptions [3.2] in that write-up does not hold in real life.  The assumption is that "standard time" offset does not depend on the point in time.  However, I do believe that this assumption can be relaxed without invalidating the main result.   I believe we can still have unambiguous fromutc() as long as standard time offset does not change "too often."  Basically, if we (generously)  allow utcoffset to vary from -24h to +24h, then a "sane" zone can be defined as the one where utcoffset changes at most once in any 48 hour period.</div><div><br></div><div>If I am right about this and the algebra works out, then we don't need to change datetime module design to properly support all world timezones. <br><br>[1] <a href="https://docs.python.org/3/library/datetime.html#datetime.tzinfo.fromutc">https://docs.python.org/3/library/datetime.html#datetime.tzinfo.fromutc</a><br>[2] <a href="http://bugs.python.org/issue9063">http://bugs.python.org/issue9063</a> <br></div><div>[3] <a href="https://hg.python.org/cpython/file/132b5376bf34/Lib/datetime.py#l1935">https://hg.python.org/cpython/file/132b5376bf34/Lib/datetime.py#l1935</a></div><div>[3.2] <a href="https://hg.python.org/cpython/file/132b5376bf34/Lib/datetime.py#l1948">https://hg.python.org/cpython/file/132b5376bf34/Lib/datetime.py#l1948</a></div></div>