[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(<any other tz>).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: 1. You're using a pre-495 tzinfo. Then nothing changes from what happens today. 2. You're using a new 495-conforming tzinfo. Then the discussion starts to apply. _______________________________________________ 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
