Message349163
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? |
|
Date |
User |
Action |
Args |
2019-08-07 11:07:54 | mehaase | set | recipients:
+ mehaase, belopolsky, jwilk, rdb, p-ganssle |
2019-08-07 11:07:54 | mehaase | set | messageid: <1565176074.16.0.828823983456.issue35829@roundup.psfhosted.org> |
2019-08-07 11:07:54 | mehaase | link | issue35829 messages |
2019-08-07 11:07:53 | mehaase | create | |
|