8000 Behavior of datetime.datetime.strptime differs from documented behavior on %z · Issue #122781 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Thomasillo opened this issue Aug 7, 2024 · 5 comments
Closed

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

Thomasillo opened this issue Aug 7, 2024 · 5 comments
Labels
extension-modules C modules in the Modules dir stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@Thomasillo
Copy link
Thomasillo commented Aug 7, 2024 •
edited by bedevere-app bot
Loading

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
@Thomasillo Thomasillo added the type-bug An unexpected behavior, bug, or error label Aug 7, 2024
@pygeek
Copy link
Contributor
pygeek commented Aug 8, 2024 •
edited
Loading

Similar to:

@bedevere-app bedevere-app bot mentioned this issue Aug 8, 2024
Open
@midnightstardust
Copy link
midnightstardust commented Aug 8, 2024 •
edited
Loading

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
Copy link
Contributor
zuo commented Oct 3, 2024

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
Copy link
Contributor
zuo commented Oct 3, 2024

(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?)

@picnixz picnixz added stdlib Python modules in the Lib dir extension-modules C modules in the Modules dir labels Oct 3, 2024
@bedevere-app bedevere-app bot mentioned this issue Apr 25, 2025
Merged
pganssle pushed a commit that referenced this issue May 20, 2025
@StanFromIreland
gh-122781: Allow empty offset for %z in strptime (#132922)
99b5808 
* commit

* Move tests
@StanFromIreland
Copy link
Contributor

cc @pganssle This can be closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
extension-modules C modules in the Modules dir stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
Projects
Date and time issues 🕰️
Status: Done
Milestone
No milestone
Development

No branches or pull requests
7 participants
@pygeek @zuo @pganssle @picnixz @Thomasillo @StanFromIreland @midnightstardust
0