Repository navigation
datetime.strftime("%Y") is not padding correctly #120713
Description
Bug report
Bug description:
docs say:
%Y
Year with century as a decimal number.
0001, 0002, …, 2013, 2014, …, 9998, 9999
but this is what is happening
from datetime import datetime
print(datetime(9, 6, 7).strftime("%Y-%m-%d")) # 9-06-07
print(datetime(99, 6, 7).strftime("%Y-%m-%d")) # 99-06-07
print(datetime(999, 6, 7).strftime("%Y-%m-%d")) # 999-06-07CPython versions tested on:
3.10
Operating systems tested on:
No response
Linked PRs
- gh-120713: normalize year with century for datetime.strftime #120820
- [3.13] gh-120713: Normalize year with century for datetime.strftime (GH-120820) #121144
- [3.12] gh-120713: Normalize year with century for datetime.strftime (GH-120820) #121145
- [3.13] Revert "[3.13] gh-120713: Normalize year with century for datetime.strftime (GH-120820) (GH-121144)" #122408
- [3.12] Revert "[3.12] gh-120713: Normalize year with century for datetime.strftime (GH-120820) (GH-121145)" #122409
- gh-120713: Make _Py_NORMALIZE_CENTURY private #135933
- [3.14] gh-120713: Make _Py_NORMALIZE_CENTURY private (GH-135933) #136387
Activity
blhsing commentedon Jun 19, 2024
Reproducible on 3.10 but not on 3.11+.
serhiy-storchaka commentedon Jun 19, 2024
cc @pganssle
I suppose that it works in such way since Python 3.0 (I tested in 3.3). 2.7 does not support years before 1900.
You can use %4Y to always get 4-digit year. I wonder whether this is a documentation issue or the output is platform depending.
blhsing commentedon Jun 19, 2024
Ah, so the issue is platform-dependent. When I reproduced the OP's issue in 3.10 I was doing it in Linux, while in Windows I tested the code in 3.11 and 3.13 and the issue was not reproduced. Now I realized that this is just a result of
datetime.strftimebeing a thin wrapper over the platform'sstrftimein the C library:According to the doc:
serhiy-storchaka commentedon Jun 20, 2024
The limitation for year >= 1000 was removed in bpo-11930 (gh-56139). But there were various problems with the newly added test
test_strftime_y2k, it required several corrections.For now, we cannot guarantee the result for %Y (and %G) with year < 1000. It is especially bad since
strptime()requires the year to be 4 digits.pythongh-120713: normalize year with century for datetime.strftime
pythongh-120713: fixed pyconfig.h.in
blhsing commentedon Jun 21, 2024
Since
datetime.strftimealready uses a wrapper function to handle format specifiers not conforming to the Cstrftime, I think a reasonable fix would be to add the translation of%Yto%4Ythere as needed by the platform to make the function portable.serhiy-storchaka commentedon Jun 21, 2024
Yes, but the problem is that %4Y is a glibc extension. There are platforms that return non-4-digit number and do not support %4Y. If we are going to guarantee 4 digits, the workaround may be much more complex.
blhsing commentedon Jun 21, 2024
With PR #120820 I've made sure that the translation is only used when explicitly supported by the platform so that it is at least an improvement and not a regression in any case. I did just revert my changes to the unit test to allow an outlier platform to pass the test.
pythongh-120713: format "%Y" with "%4d" using sprintf instead of repl…
pythongh-120713: test that a 0-padded year with century is guaranteed
blhsing commentedon Jun 24, 2024
On second thought, guaranteeing 4 digits is actually not complex since we can simply format the year with
"%04ld"usingsprintf, which works on all platforms.I've updated the PR accordingly so that a 4-digit year with century can now be guaranteed.
pythongh-120713: revised detection logics in Python
51 remaining items
blhsing commentedon Sep 4, 2024
Thanks for the heads-up. It is weird indeed that this can happen since according to the build log the configure script did detect that the platform would not 0-pad a century so the handler for
%Ywould format the year itself withsnprintfusing the"%04ld"format string.Since this happens only on
aarch64perhaps there is indeed some peculiarity ofsnprintfin the glibc of that platform.Will try debugging this on a Mac later.
It's a bug fix but was found to be incomplete, due to issue #122272.
serhiy-storchaka commentedon Sep 4, 2024
Please open a new issue and provide more details.
picnixz commentedon Sep 4, 2024
See #123681.
pythongh-120713: Make _Py_NORMALIZE_CENTURY private
gh-120713: Make _Py_NORMALIZE_CENTURY private (GH-135933)
pythongh-120713: Make _Py_NORMALIZE_CENTURY private (pythonGH-135933)
[3.14] gh-120713: Make _Py_NORMALIZE_CENTURY private (GH-135933) (#13…
pythongh-120713: Make _Py_NORMALIZE_CENTURY private (pythonGH-135933)
pythongh-120713: Make _Py_NORMALIZE_CENTURY private (pythonGH-135933)
pythongh-120713: Make _Py_NORMALIZE_CENTURY private (pythonGH-135933)
pythongh-120713: Make _Py_NORMALIZE_CENTURY private (pythonGH-135933)
pythongh-120713: Make _Py_NORMALIZE_CENTURY private (pythonGH-135933)
Work around Python strftime bug
icloudpd: build with python313
fix: zero-pad early creation years on the detail page