[Python-Dev] PEP 495 accepted (original) (raw)
Tim Peters tim.peters at gmail.com
Tue Sep 22 17:11:03 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 ]
[Nick Coghlan]
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()".
[Guido]
That can't be right -- There is no way any fromtimestamp() call can return a time in the gap.
[Alexander Belopolsky]
I don't think Nick said that.
I do, except that he didn't ;-) Count the parens carefully. The top-level operation on the RHS is datetime.fromtimestamp(). However, it didn't pass a tzinfo, so it creates a naive datetime. Assuming dt was aware to begin with, the attempt to compare will always (gap or not) raise an exception. If it had passed dt.tzinfo, then Guido is right.
I think about the only useful invariant here is
dt.timestamp() == dt.astimezone(utc).timestamp() == dt.astimezone().timestamp()
Yes, this is just another way to say that .astimezone() conversions are now
Nick, to be very clear, there are two scenarios here after PEP 495 is implemented in Python:
You're using a pre-495 tzinfo. Then nothing changes from what happens today.
You're using a new 495-conforming tzinfo. Then the discussion starts to apply.
- 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 ]