homepage

Locale-based date formatting in py3k (using strftime) crashes when asked
to format a month name (or day, I assume) containing non-ASCII characters:
>>> import time
>>> import locale
>>> time.strftime("%B", (2009,2,1,0,0,0,0,0,0))
'February'
>>> locale.setlocale(locale.LC_TIME, "fr_FR")
'fr_FR'
>>> time.strftime("%B", (2009,2,1,0,0,0,0,0,0))
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-3:
invalid data
It works if I specify the encoding explicitly in the locale name so as
to coincide with the encoding specified in the error message above (but
that's assuming the given encoding-specific locale *is* installed):
>>> locale.setlocale(locale.LC_TIME, "fr_FR.UTF-8")
'fr_FR.UTF-8'
>>> time.strftime("%B", (2009,2,1,0,0,0,0,0,0))
'février'

(if I explicitly set another encoding, it doesn't work however:
>>> locale.setlocale(locale.LC_TIME, "fr_FR.ISO-8859-1")
'fr_FR.ISO-8859-1'
>>> time.strftime("%B", (2009,2,1,0,0,0,0,0,0))
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-3:
invalid data
)

I think the problem is that creation of the Unicode string defaults to 
UTF-8. It should instead use the locale's encoding.
You are right that it could be an issue that there is no Python codec 
for the locale's encoding. To be robust against this case, I think the 
locale's mbcs->wcs routines should be used (i.e. mbstowcs). Better yet, 
use wcsftime in the first place. AFAICT, wcsftime is C99, so not all 
systems might support it. However, it appears that MSVC has it, so we 
could assume it exists and wait until someone complains. One issue 
apparently is that some implementations of wcsftime expect the format as 
char* (and again, I would defer dealing with that until somebody 
complains).
In either case, you end up with a wchar_t. In principle, the locale 
might use a non-Unicode wide charset for wchar_t, but these got out of 
use some time ago, and Python had always assumed that wchar_t is 
Unicode.

This is a duplicate of issue 3061.