[Datetime-SIG] Adding PEP 495 support to dateutil
tim.peters at gmail.com
Sat Sep 19 03:02:21 CEST 2015
>> 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
>> Which is what pytz does.
> The pytz hack is in violation of the strict reading of the reference manual
>  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.
More information about the Datetime-SIG