On 23 September 2015 at 01:09, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > > On Tue, Sep 22, 2015 at 10:55 AM, Alexander Belopolsky > <alexander.belopol...@gmail.com> wrote: >> >> On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum <gu...@python.org> >> wrote: >>>> >>>> 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()". >>> >>> >>> That can't be right -- There is no way any fromtimestamp() call can >>> return a time in the gap. >> >> >> I don't think Nick said that. > > On the second reading, it looks like Nick's second sentence contradicts his > first. Guido is right. Moreover, there is no way to get a time in the gap > as a result of any conversion including astimezone() and fromutc() in > addition to fromtimestamp(). Such datetimes may appear if you construct > them explicitly, use .replace() to transplant a datetime to another timezone > (or modify other components) and in the result of datetime + timedelta > operation.
Sorry, what I wrote in the code wasn't what I wrote in the text, but I didn't notice until Guido pointed out the discrepancy. To get the right universal invariant, I should have normalised the LHS, not the RHS: dt.astimezone(utc).astimezone(dt.tzinfo) == datetime.fromtimestamp(dt.timestamp()) For unambiguous times and times in the fold, that's a subset of the stronger invariant: dt == dt.astimezone(utc).astimezone(dt.tzinfo) == datetime.fromtimestamp(dt.timestamp()) That stronger invariant is the one that *doesn't* hold for times in the gap, as with fold=0 they'll get normalised to use the right UTC offset (same UTC time, nominally an hour later local time), while with fold=1 they get mapped to an hour earlier in both UTC and local time. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com