Behavior of datetime.datetime.strptime differs from documented behavior on %z

[Thomasillo]

Bug report

Bug description:

import datetime
datetime.datetime.strptime("2024-03-21T15:49:51", '%Y-%m-%dT%H:%M:%S%z')

will fail with ValueError: time data '2024-03-21T15:49:51' does not match format '%Y-%m-%dT%H:%M:%S%z'

From the documentation for strptime, empty string should be allowed here.

%z	UTC offset in the form ±HHMM[SS[.ffffff]] (empty string if the object is naive).	(empty), +0000, -0400, +1030, +063415, -030712.345216	(6)

NB: strftime behaves correctly.

 >>> datetime.datetime.strftime(datetime.datetime(2024, 3, 21, 15, 49, 51),  '%Y-%m-%dT%H:%M:%S%z')
'2024-03-21T15:49:51'

So strptime(strftime(datetime.datetime(2024, 3, 21, 15, 49, 51), '%Y-%m-%dT%H:%M:%S%z'), '%Y-%m-%dT%H:%M:%S%z') would fail.

CPython 3.12.4, WSL2 (Ubuntu 20.04)

CPython versions tested on:

3.12

Operating systems tested on:

Linux

Linked PRs

• gh-122781: fix time format bug #122829
• gh-122781: Fix %z in strptime #132922

[pygeek]

Similar to:

• https://bugs.python.org/issue6641
• https://bugs.python.org/issue22377

[midnightstardust]

Linked a PR where I made %z allow an optional utc offset instead of mandating a utc offset, would appreciate it if someone could take a look, thanks!

#122829

[zuo]

Making %z-parsing accept an empty string looks to me like a serious behavioral change, as it is almost obvious to me that non-negligible number of users rely on %z to distinguish and accept only a timezone-aware date+time (rejecting timezone-less aka naive ones).

cc @pganssle

[zuo]

(I believe that rejecting %z when formatting a naive (tz-unaware) datetime would be a better idea – but now, in 2024, is probably a non-starter, because of the incompatibility impact. Although, perhaps after full 5-years deprecation period it would be acceptable?)

[StanFromIreland]

cc @pganssle This can be closed