`date.strftime` and `datetime.strftime` format dates wrong in some locales.

[petergraham]

Bug report

Bug description:

date.strftime and datetime.strftime format dates wrong in some locales. For example, when the locale is Bulgaria the '%A' format string returns an incorrect value.

>>> locale.setlocale(locale.LC_TIME, 'bg')    # 'bg' is Bulgaria
>>> date_str = datetime.date(2025, 2, 25).strftime('%A') # %A is locale's day of the week
>>> date_str
'âòîðíèê'
>>> date_str.encode('cp1252').decode('cp1251')  # I think we're interpreting a cp1251 string as cp1252
'вторник'  # Google tells me this is Tuesday in Bulgarian

This also fails with the '%x' format string

I've only tested this on Windows.

My guess is that CPython is making a narrow character API call and using the wrong code page. It should be using the wide character call instead.

CPython versions tested on:

3.13

Operating systems tested on:

Windows

[picnixz]

Err, my question may be dumb, but aren't we Tuesday? Or do you mean that date_str is incorrectly rendered first?

EDIT: Oh ok, I missed the 1-off page example. I've read cp1251 twice so I wondered what was the issue.

[picnixz]

Ok, second question. I think what's being returned with %A is encoded with something that is not necessarily useful for the LC_TIME language. CP-1252 is a legacy default format on Windows according to Wikipedia, and I assume that it's as if we had "no localized encoding".

@serhiy-storchaka you're more of an expert in this case, is it the expected behaviour? namely, should we expect the caller to actually perform the encode/decode themselves or is it something that's wrong with datetime?

[tomasr8]

I think locale.getlocale(locale.LC_TIME)[1] should return the encoding used by strftime

[serhiy-storchaka]

Oh-oh, it is yet one issue similar to #69998 and bpo-28604. The workaround at he user side is to set LC_CTYPE to the same value as LC_TIME. We can fix this at Python side, but at the cost of making strftime() slower and potentially more thread-unsafe (it is already not thread-safe in sense that it can fail if the environment is changed in other thread, but now it will be able to break other threads by changing the environment).

[donBarbos]

I reproduce your case on Linux, so first of all, if you don't have locale (you can check it with locale -a command), you will get locale.Error: unsupported setting, but all available locales were utf8 so I think there was no error:

>>> locale.setlocale(locale.LC_TIME, 'ka_GE.utf8')
'ka_GE.utf8'
>>> datetime.date(2025, 2, 25).strftime('%A')
'სამშაბათი' # Tuesday
>>> locale.setlocale(locale.LC_TIME, 'ka_GE')
Traceback (most recent call last):
  File "<python-input-8>", line 1, in <module>
    locale.setlocale(locale.LC_TIME, 'ka_GE')
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "./lib/python3.13/locale.py", line 615, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

(I checked the behavior on the main branch and also version 3.13)

[StanFromIreland]

>>> locale.setlocale(locale.LC_TIME, 'bg_BG')
'bg_BG'
>>> print(datetime.date(2025, 2, 25).strftime('%A'))
вторник
>>> locale.setlocale(locale.LC_TIME, 'bg_BG.UTF-8')
'bg_BG.UTF-8'
>>> print(datetime.date(2025, 2, 25).strftime('%A'))
вторник
>>> locale.setlocale(locale.LC_TIME, 'bg_BG.cp1251')
'bg_BG.cp1251'
>>> print(datetime.date(2025, 2, 25).strftime('%A'))
вторник

Unable to reproduce on Linux, maybe this has something to do with how Windows is configured? That seems to be the case for other similar issues.