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.
_______________________________________________ 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
