<div dir="ltr"><div class="gmail_extra"></div><br>On Fri, Sep 18, 2015 at 2:42 PM, Tim Peters <<a href="mailto:tim.peters@gmail.com">tim.peters@gmail.com</a>> wrote:<br>><br>> When converting from UTC to a local ambiguous time, you obviously know<br>> which UTC time you started with.  The problem is that it's impossible<br>> to _record_ which UTC time you started with.  The date and time<br>> attributes of the local datetimes are (must be) identical, so the only<br>> way you _could_ record it is by overriding .fromutc() to attach a<br>> different tzinfo object (the only bits of a datetime object that could<br>> possibly differ between the earlier and later of an ambiguous local<br>> time).<br>><br>> Which is what pytz does. <br><br>The pytz hack is in violation of the strict reading of the reference manual [1] which says "The purpose of fromutc() is to adjust the date and time data ...".  I think it is in the spirit if not in the letter of datetime module design that fromutc(dt) should not change dt.tzinfo.<div><br></div><div>In any case, I think we have concluded on this list that pytz approach is not an example to be followed.  I just wanted to mention for Paul's benefit that it is not just the arithmetic that is affected by the pytz hack.  The changes in arithmetic are themselves consequences of the violation of the "fromutc(dt).tzinfo is dt.tzinfo" invariant.<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></div></div>