[Paul Ganssle <[email protected]>] > .. > 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). _______________________________________________ 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/
