homepage

On Windows XP, with some locales the month name
returned by time.strftime('%B') is encoded somehow. 
For example:
>>> import time, locale
>>> locale.setlocale(locale.LC_ALL, '')
"Chinese_People's Republic of China.936"
>>> time.strftime('%B')
'\xca\xae\xd2\xbb\xd4\xc2'
>>> time.strftime('%d %B %Y')
'05 \xca\xae\xd2\xbb\xd4\xc2 2003'
>>> locale.setlocale(locale.LC_ALL, '')
'French_France.1252'
>>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0))
'd\xe9cembre'
I'm not sure what encoding the Chinese version is
using, but the French is compatible with latin-1. It
would appear that the encoding used is locale-dependent.
Ideally, the win32 version of time.strftime would call
the wide-character version of strftime (called
wcsftime) and return a unicode object.
I haven't looked at what this does under any other
operating system.

Logged In: YES 
user_id=21627
It always contains a byte string in the locale's encoding;
for compatibility, this cannot be changed.
On Windows, you can access the encoding as "mbcs". In
general, you need to use locale.getpreferredencoding() to
find out what encoding this string is in.
Closing as not-a-bug.

Logged In: YES 
user_id=561705
I'm reopening the bug, because that doesn't seem to work:
>>> import time, locale
>>> locale.setlocale(locale.LC_ALL, '')
"Chinese_People's Republic of China.936"
>>> x = time.strftime('%B')
>>> x
'\xca\xae\xd2\xbb\xd4\xc2'
>>> x.decode('mbcs')
'\xca\xae\xd2\xbb\xd4\xc2'
>>> locale.getpreferredencoding()
'cp1252'
>>> x.decode('cp1252')
'\xca\xae\xd2\xbb\xd4\xc2'
The preferred encoding is returned as cp1252, which can't be
correct. And niether cp1252 nor mbcs appear to decode the
string into anything containing the high-numbered characters
I would expect for chinese (neither of them changes the
string at all).
The following problems (may) exist:
1. locale.getpreferredencoding() doesn't work.
2. The string return by time.strftime() is not mbcs encoded.
3. The documentation for time.strftime() doesn't say how
the string is encoded.

Logged In: YES 
user_id=38388
Tim, there's nothing much we can do about this since the
strftime()
API is a direct interface to the underlying C lib API. Python
simply passes through the arguments to this function and
returns whatever teh C lib has to offer.
Please refer to the C lib documentation for your platform
for details about the encoding being used for the strings.
BTW, a simpe table with the month names in your application
should nicely solve your problem; addtitionally it gives you
full control ove the encoding and wording being used.

Logged In: YES 
user_id=561705
The windows C lib docs say that calling mbstowcs on the
output of strftime (or calling wcsftime instead of strftime)
will return the correct wide-character (utf-16?) string. 
This produces something that looks like it could be correct.
 Decoding with the 'mbcs' encoding in Python is not
equivalent to calling mbstowcs because mbstowcs is
locale-dependent.
Perhaps it would be a good idea to have time.strftime return
a unicode string. As this wouldn't be backward compatible,
it could be done via a new function time.ustrftime, or via
an optional unicode=True argument to the existing function.

Logged In: YES 
user_id=21627
Is there any way to find out the encoding that mbstowcs uses?

Logged In: YES 
user_id=561705
I have looked at the source code for the MS C library (it
comes with VC++6) and I believe that that something
equivalent to the following is used:
char codepage[16];
GetLocaleInfo(
 GetThreadLocale(),
 LOCALE_IDEFAULTANSICODEPAGE,
 codepage, 16);
This returns "1252" for "C" locale, and for the chinese
locale that I was expirmenting with it returns "936". 
Python does not have an encoding "cp936", but from C the
conversion with an explicit codepage produces the same
results as mbstwcs.

Logged In: YES 
user_id=21627
This tells me that we need a function to return the current
locale's code page; this should return "cp936" in your case.
The fact that Python does not have a codec for cp936 is an
independent issue.

Is this still an issue in 3.x? With time.strftime() returning unicode, I don't think any encoding issues remain.

Closed as no reply to msg107343.