Mark Haase <meha...@gmail.com> added the comment:
Defining isoformat() and fromisoformat() as functional inverses is misguided.
Indeed, it's not even true:
```
Python 3.7.2 (default, Dec 28 2018, 14:27:11)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> s = '2019-08-07t10:44:00+00:00'
>>> assert s == datetime.isoformat(datetime.fromisoformat(s))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AssertionError
```
I agree with rdb that not parsing "Z" is inconvenient and counter intuitive. We
have the same use case: parsing ISO strings created by JavaScript (or created
by systems that interoperate with JavaScript). We have also memorized the same
`.replace("Z", "+00:00")` hack, but this feels like a missing battery in the
stdlib.
As Paul points out the legacy of isoformat() complicates the situation. A new
pair of functions for RFC-3339 sounds reasonable to me, either
rfcformat()/fromrfcformat() or more boldly inetformat()/frominetformat(). The
contracts for these functions are simple: fromrfcformat() parses RFC-3339
strings, and rfcformat() produces an RFC-3339 string. The docs for the ISO
functions should be updated to point towards the RFC-compliant functions.
I'd be willing to work on a PR, but a change of this size probably needs to
through python-ideas first?
----------
nosy: +mehaase
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
