Open za3k opened 1 month ago
Wouldn't %:z
have to reject -0400
?
Reasonable question. Shouldn't %z
reject -04:00
? It doesn't, currently.
Both should parse the alternative format, or neither, for the sake of consistency.
The current behavior for %z
is old (predates %:z
from 3.12). I would argue for both to avoid breaking backwards compatibility.
In my view :
is optional for %z
, so it's not used in strftime()
, while it's required in %:z
.
If we enforce this, this actually allows something new instead of an alternative way to do it:
There should be one-- and preferably only one --obvious way to do it.
This should probably be labeled as a new feature.
I think either implementation would be an improvement. I raise no objection :)
@Eclips4 can you add the feature label?
I'll be taking care of this one
As dicussed, we need to have consistency across strptime
and strftime
, while keeping backwards compatibility.
%z
and %:z
work as expected in strftime
, so no need to change anything there.%z
does what it should in strptime
, while in addition allowing %:z
-formatted strings too (see third comment). We should keep this behavior for backwards compatibility.%:z
fails in strptime
. We should allow %:z
there and make it parse only %:z
-formatted strings.I added a PR addressing the issue: https://github.com/python/cpython/pull/122142
Bug report
Bug description:
https://docs.python.org/3/library/datetime.html#strftime-and-strptime-format-codes documents "strftime() and strptime() Format Codes". It mentions the new %:z variant of %z, introduced in Python 3.12
But passing "%:z" to strptime raises an error. This is a bug because strptime and strftime should have the same format codes, according to the docs.
Since %z already parses this format when passed to strptime, I think %:z should just do the same thing.
Workaround: Change
%:z
to%z
in your format string forstrptime
.CPython versions tested on:
3.12
Operating systems tested on:
Linux
Linked PRs