[Datetime-SIG] Adding PEP 495 support to dateutil

[Tim Peters]

[Paul Ganssle <paul at ganssle.io>]
> ..
> It's a separate question as to whether it can or cannot do better in some
> cases. The issues I linked to are both cases where an unambiguously
> specified time ("now" or a time specified in UTC with an IANA time zone) are
> incorrectly converted into local time. It is almost certainly true that
> enough information is available to properly localize these datetimes, but at
> least in the case of localizing "now" the cost in doing so is additional
> complexity on the back-end.

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.  But then the semantics of arithmetic changes
too, because datetime subtraction and comparison do different things
depending on whether or not the datetimes' tzinfo objects are
identical (same object).

This is why POSIX has a tm_isdst flag in a struct tm (the POSIX
spelling of a Python datetime), to record whether an ambiguous local
time is intended to be the earlier or later.  PEP 495's new `fold`
flag is the same so far as DST transitions go, but is also clearly
applicable to all possible causes of folds (including a zone's
"standard" offset changing).