Here is the PR I've submitted:
The contract that I'm supporting (and, I think it can be argued, the only reasonable contract in the intial implementation) is the following:
dtstr = dt.isoformat(*args, **kwargs) dt_rt = datetime.fromisoformat(dtstr) assert dt_rt == dt # The two points represent the same absolute time assert dt_rt.replace(tzinfo=None) == dt.replace(tzinfo=None) # And the same wall time
For all valid values of `dt`, `args` and `kwargs`.
A corollary of the `dt_rt == dt` invariant is that you can perfectly recreate the original `datetime` with the following additional step:
dt_rt = dt_rt if dt.tzinfo is None else dt_rt.astimezone(dt.tzinfo)
There is no way for us to guarantee that `dt_rt.tzinfo == dt.tzinfo` or that `dt_rt.tzinfo is dt.tzinfo`, because `isoformat()` is slightly lossy (it loses the political zone), but this is not an issue because lossless round trips just require you to serialize the political zone, which is generally simple enough.
On 12/06/2017 07:54 PM, Barry Scott wrote:
On 26 Oct 2017, at 17:45, Chris Barker email@example.com wrote:
This is a key point that I hope is obvious:
If an ISO string has NO offset or timezone indicator, then a naive datetime should be created.
(I say, I "hope" it's obvious, because the numpy datetime64 implementation initially (and for years) would apply the machine local timezone to a bare iso string -- which was a f-ing nightmare!)
I hope the other obvious thing is that if there is a offset then a datetime that is *not* naive can be created as it describes an unambiguous point in time. We just cannot know what political timezone to choose. I'd guess that it should use the UTC timezone in that case.
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/paul%40ganssle.io