[Tim] >> When converting from UTC to a local ambiguous time, you obviously know >> which UTC time you started with. The problem is that it's impossible >> to _record_ which UTC time you started with. The date and time >> attributes of the local datetimes are (must be) identical, so the only >> way you _could_ record it is by overriding .fromutc() to attach a >> different tzinfo object (the only bits of a datetime object that could >> possibly differ between the earlier and later of an ambiguous local >> time). >> >> Which is what pytz does.
[Alex] > 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. It's certainly "in the spirit" not to change it. I wrote that part of the docs, and it never occurred to me that anyone would even _consider_ changing it ;-) > In any case, I think we have concluded on this list that pytz approach is > not an example to be followed. Well, it was dead easy to establish it wasn't Guido's intent as the primary original designer, or my intent as the primary original implementer & doc author - all anyone ever had to do to establish _that_ was to ask us ;-) I happen to still believe that a "hybrid" tzinfo is the best approach, but appreciate that pytz solved a world of problems with its approach (while creating others). I really can't tell if a consensus has been reached among the relative handful of datetime-SIG participants. Which means there is no consensus. > 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. Paul, something else you should know: you don't _have_ to change anything if PEP 495 is implemented. That alone shouldn't change any results dateutil computes in any case. datetuil will simply ignore `fold` then, and compute the same results it computes today. The intent is to make it _possible_ for dateutil to get conversions exactly right in every case, which it cannot do today. _______________________________________________ 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/
