[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Paul Ganssle added the comment: I don't think it's necessary to add a feature to `isoformat()` just for the purpose of being able to add the corresponding parser, particularly when the plan is to implement a much broader ISO 8601 parser for Python 3.11 (I've done most of the implementation i

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Matt Wozniski added the comment: I agree with Brett. Adding `allow_z` (or perhaps `compact` or `use_utc_designator` if we're bikeshedding) as an optional keyword only argument to `.isoformat()` would allow us to keep the explanation that what `.fromisoformat()` can parse is exactly what `.is

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Brett Cannon added the comment: I also support the idea of adding an `allow_Z` or some equivalent keyword parameter to isoformat() and then allowing for `Z` in `fromisoformat()`. -- nosy: +brett.cannon ___ Python tracker

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Daniel Lenski added the comment: Like many others here, I've run into this issue because I'm trying to parse timestamps from JSON. (Specifically, I'm trying to parse timestamps from JSON serialization of Java POJOs and/or Kotlin data classes, as serialized by the Jackson serialization libra

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Change by Daniel Lenski : -- nosy: +dlenski ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Ammar Askar added the comment: There's been some additional discussion on https://discuss.python.org/t/parse-z-timezone-suffix-in-datetime/2220 -- nosy: +ammar2 ___ Python tracker __

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Alex Grönholm added the comment: Has this effort gone forwards lately, or has there been any discussion elsewhere? I implemented support for "Z" in .fromisoformat() before finding this issue. Even after reading the discussion I still don't quite understand why it's such a big problem. --

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Paul Ganssle added the comment: > Defining isoformat() and fromisoformat() as functional inverses is misguided. > Indeed, it's not even true: `isoformat()` is not the inverse of `fromisoformat()`, that doesn't work because there are multiple strings that isoformat() can create from any given

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Change by hongweipeng : -- nosy: +hongweipeng ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Mark Haase 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 inf

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Change by Jakub Wilk : -- nosy: +jwilk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Paul Ganssle added the comment: > It seems a little odd to need to pull in a third-party library for this; it > seems far more tempting for me to just do > "datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I know my > dates are produced by a JSON API. Yes, this is also a vi

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

rdb added the comment: > > From a cursory glance at the RFC3339 spec it looks like the only other > > change needed to fully support RFC3339 would be to support an arbitrary > > number of sub-second digits, whereas fromisoformat() currently requires > > either exactly 3 or 6. > > There are o

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Paul Ganssle added the comment: > I can see your point in not causing confusion about what this method is > meant to be used for. In this case, making it easy to explain what it does is less important than making the scope and contract of the function clear so that we don't have to argue a

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

rdb added the comment: I'm a fan of "be lenient in what you accept" but I can see your point in not causing confusion about what this method is meant to be used for. Because what I'm trying to use it for technically falls outside the intended use, I say it would make the most sense to expand

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Paul Ganssle added the comment: You can see the discussion in bpo-15873 for the full rationale of why "Z" was omitted - to quote from https://bugs.python.org/issue15873#msg307607 : > We can have further discussion later about what exactly should be supported > in Python 3.8, > but even in th

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Change by Karthikeyan Singaravelan : -- nosy: +belopolsky, p-ganssle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

New submission from rdb : The fromisoformat() function added in 3.7 is a very welcome addition. But one quite noticeable absence was the inability to parse Z instead of +00:00 as the timezone suffix. Its absence is particularly noticeable given how ubiquitous use of Z is in ISO 8601 timesta