`datetime.strftime("%Y")` is not padding correctly

[martinvuyk]

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-07

CPython 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

[blhsing]

Reproducible on 3.10 but not on 3.11+.

[serhiy-storchaka]

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]

I wonder whether this is a documentation issue or the output is platform depending.

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.strftime being a thin wrapper over the platform's strftime in the C library:

According to the doc:

The full set of format codes supported varies across platforms, because Python calls the platform C library’s strftime() function, and platform variations are common. To see the full set of format codes supported on your platform, consult the strftime(3) documentation.

[serhiy-storchaka]

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.

[blhsing]

Since datetime.strftime already uses a wrapper function to handle format specifiers not conforming to the C strftime, I think a reasonable fix would be to add the translation of %Y to %4Y there as needed by the platform to make the function portable.

[serhiy-storchaka]

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]

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.

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.

[blhsing]

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.

On second thought, guaranteeing 4 digits is actually not complex since we can simply format the year with "%04ld" using sprintf, which works on all platforms.

I've updated the PR accordingly so that a 4-digit year with century can now be guaranteed.