[Python-Dev] PEP 495 accepted (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Sep 22 09:01:32 CEST 2015
- Previous message (by thread): [Python-Dev] PEP 495 accepted
- Next message (by thread): [Python-Dev] PEP 495 accepted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 22 September 2015 at 13:33, Nick Coghlan <ncoghlan at gmail.com> wrote:
On 22 September 2015 at 08:03, Guido van Rossum <guido at python.org> wrote:
Just so people know, over at the datetime-sig I've accepted PEP 495, which adds a fold flag to datetime objects to distinguish ambiguous times. This enables roundripping of conversions for those times where the local clock is moved backward (creating ambiguous times that could not be distinguished before). Hurrah, and congratulations in particular on finding a name for the flag which is memorable, meaningful and succinct.
I would like to thank Alexander and Tim for their unrelenting work on this. The idea seems simple, but the details were excruciatingly hard to get right, given the strict backwards compatibility requirements. I don't think I've seen a collision between mathematical and language level invariants that complex since the first time I had to figure out the conflict between container membership invariants and floating point NaN values (and this one is even more subtle). I'm reading through the full PEP now, and really appreciating the thorough write up. Thanks to Alexander and Tim, and to all the folks involved in the extensive discussions!
It turns out there's one aspect of the accepted proposal that I think I understand, but want to confirm: the datetime -> POSIX timestamp -> datetime roundtrip for missing times.
If I'm reading the PEP correctly, the defined invariant for local times that actually exist is:
dt == datetime.fromtimestamp(dt.timestamp())
No confusion there for the unambiguous times, or for times in a fold. In the latter case, the timestamps produced match the points where the UTC times match the local times in the "In the Fold" UTC/local diagram.
The subtle part is the handling of the "timestamp()" method for the "missing" times where the given time doesn't actually correspond to a valid time in the applicable timezone (local time for a naive datetime object).
Based on the UTC/local diagram from the "Mind the Gap" section, am I correct in thinking that the modified invariant that also covers times in a gap is:
dt == datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzinfo).timestamp())
That is, for local times that exist, the invariant "dt == dt.astimezone(utc).astimezone(dt.tzinfo)" holds, but for times that don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise them to be a time that actually exists in the original time zone, and that normalisation also effectively happens when calling "dt.timestamp()".
Regards, Nick.
P.S. Thanks to whoever drew the diagrams for the In the Fold/Mind the Gap sections - I found them incredibly helpful in understanding the change!
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] PEP 495 accepted
- Next message (by thread): [Python-Dev] PEP 495 accepted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]