[Datetime-SIG] Adding PEP 495 support to dateutil

[Tim Peters]

[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.