Solved--Why does python not support the `Z` suffix for UTC timezone?

Python Help
1

We can put Z at the end to express zero timezone according to ISO8601.
[ISO 8601 - Wikipedia](https://iso8601 introduction)

“2024-01-01T02:32:21Z” is the right format in ISO8601.

>>> s = "2024-01-01T02:32:21Z"
>>> dt = datetime.datetime.fromisoformat(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid isoformat string: '2024-01-01T02:32:21Z'
>>> s = "2024-01-01T02:32:21"
>>> dt = datetime.datetime.fromisoformat(s)
>>> dt
datetime.datetime(2024, 1, 1, 2, 32, 21)

It is a good habit to comply with standard ,why python doesn’t support it?

2

Hmm. I think that may have come in very recently, because the Python builds that I have actually DO support that:

>>> import datetime
>>> datetime.datetime.fromisoformat("2024-01-01T02:32:21Z")
datetime.datetime(2024, 1, 1, 2, 32, 21, tzinfo=datetime.timezone.utc)

With exactly the semantics that I would expect. Now, I wanted to say that this would have been introduced when timezone support was added to the datetime module, but it wasn’t:

Python 3.11.0a1+ (heads/pep-671:2601ebc9cd, Dec  1 2021, 19:18:04) [GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> datetime.timezone.utc
datetime.timezone.utc
>>> datetime.datetime.fromisoformat("2024-01-01T02:32:21Z")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid isoformat string: '2024-01-01T02:32:21Z'

So I’m not exactly sure when it was added, or whether it’s simply a matter of Python version or if you need something else. But the support is definitely there in the version I’m using (3.13, built a couple months ago).

1 Like
3

It works in 3.11 and later.

$ python3.12 -c 'import sys, datetime;print(sys.version_info,datetime.datetime.fromisoformat("2024-01-01T02:32:21Z"))'
sys.version_info(major=3, minor=12, micro=1, releaselevel='final', serial=0) 2024-01-01 02:32:21+00:00

$ python3.11 -c 'import sys, datetime;print(sys.version_info,datetime.datetime.fromisoformat("2024-01-01T02:32:21Z"))'
sys.version_info(major=3, minor=11, micro=5, releaselevel='final', serial=0) 2024-01-01 02:32:21+00:00

$ python3.10 -c 'import sys, datetime;print(sys.version_info,datetime.datetime.fromisoformat("2024-01-01T02:32:21Z"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: Invalid isoformat string: '2024-01-01T02:32:21Z'

Time to update to the release version!

4

Heh. I only have a very small number of release versions of Python - mostly, I just keep building from source, installing, and carrying on. So my “python3” command is forever updating, but every once in a while it changes its announced version number, and leaves one behind. I actually have a Python 3.11 from Debian, but it’s in /usr/bin/python3.11 and my personally-built one is in /usr/local/bin/python3.11 which takes precedence. Forgot that I have the Debian one though, or I would have tested it as well.

But the reason I didn’t go into too much detail was that I wasn’t sure whether it was a version matter or something else (like having pytz installed via pip).