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

[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.

[serhiy-storchaka]

PR #120820 looks good if this is what we want to get. @pganssle, what are your thoughts?

Note that %G also needs a fix.

[blhsing]

Note that %G also needs a fix.

Good point. I've updated the PR to account for '%G' then. Thanks.

[picnixz]

@serhiy-storchaka @blhsing I'm not sure why but we are seeing failures on JIT for the test_strftime_y2k on emulated Linux. Is it because emulated Linux have (yet) another weird case of glibc? Also, the reason we reverted the commits on 3.12 and 3.13 was because it was more of a feature than a bugfix?

[blhsing]

I'm not sure why but we are seeing failures on JIT for the test_strftime_y2k on emulated Linux. Is it because emulated Linux have (yet) another weird case of glibc?

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 %Y would format the year itself with snprintf using the "%04ld" format string.

Since this happens only on aarch64 perhaps there is indeed some peculiarity of snprintf in the glibc of that platform.

Will try debugging this on a Mac later.

Also, the reason we reverted the commits on 3.12 and 3.13 was because it was more of a feature than a bugfix?

It's a bug fix but was found to be incomplete, due to issue #122272.

[serhiy-storchaka]

Please open a new issue and provide more details.

[picnixz]

See #123681.