This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: time.strftime() always decodes result with UTF-8
Type: Stage:
Components: Versions: Python 3.0, Python 3.1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: loewis Nosy List: asmodai, benjamin.peterson, ezio.melotti, georg.brandl, jcea, loewis, tejas81
Priority: release blocker Keywords: patch

Created on 2008-06-08 08:44 by georg.brandl, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
wcsftime.diff loewis, 2009-05-29 17:29
Messages (11)
msg67828 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-06-08 08:44
It decodes the system strftime's result using TZNAME_ENCODING which is
also used to decode timezone names.  This may be correct for timezone
names themselves (I don't know), but the strftime result is encoded in
the LC_TIME encoding - at least on my Linux system.
msg86949 - (view) Author: Jeroen Ruigrok van der Werven (asmodai) * (Python committer) Date: 2009-05-02 14:53
As C99 section 7.23.3.5 states:

"Each conversion specifier is replaced by appropriate characters as
described in the following list. The appropriate characters are
determined using the LC_TIME category of the current locale and by the
values of zero or more members of the broken-down time structure pointed
to by timeptr, as specified in brackets in the description."
msg87295 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-05 22:31
Is it possible to find out what specific encoding is being used?

In most cases, nl_langinfo(CODESET) would be the right choice, but that
depends on the LC_CTYPE category. If available, wcsftime should be used.

In any case, I think issue5903 and issue5562 are related. We should
close some of them as duplicates.
msg88518 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-29 17:29
Here is a patch that resolves this issue for systems supporting
wcsftime, which should be the majority of systems on which the problem
can occur.
msg88521 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-05-29 18:44
The patch looks good. (Can this be tested?)
msg88524 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-29 19:29
It's difficult to test. The only test I can think of is one that gets
skipped if the fr_FR (say) locale is not configured. The test would then
try to find out what the name of February is, which should return a
string (see issue5562).
msg88532 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-05-29 20:31
Can you use test_support.run_with_locale?
msg88547 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-29 22:52
Benjamin Peterson wrote:
> Benjamin Peterson <benjamin@python.org> added the comment:
> 
> Can you use test_support.run_with_locale?

I don't think so. IIUC, run_with_locale will fallback to not
setting the locale if none of the listed locales actually works
on the system. This would be undesirable for this issue - it
would be a proper test only if you have a locale for which
strftime currently fails (i.e. returns non-ASCII characters,
and doesn't use UTF-8).
msg88548 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-05-29 22:55
2009/5/29 Martin v. Löwis <report@bugs.python.org>:
>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> Benjamin Peterson wrote:
>> Benjamin Peterson <benjamin@python.org> added the comment:
>>
>> Can you use test_support.run_with_locale?
>
> I don't think so. IIUC, run_with_locale will fallback to not
> setting the locale if none of the listed locales actually works
> on the system. This would be undesirable for this issue - it
> would be a proper test only if you have a locale for which
> strftime currently fails (i.e. returns non-ASCII characters,
> and doesn't use UTF-8).

Well, I think you should just apply the patch then.
msg88564 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-05-30 06:16
Committed as r73043, r73044
msg99981 - (view) Author: tejas (tejas81) Date: 2010-02-24 00:34
I came onto this ticket via #5562, does anyone know of a similar ticket/bugfix for Python 2.6?
History
Date User Action Args
2022-04-11 14:56:35adminsetgithub: 47311
2010-11-24 01:29:04jceasetnosy: + jcea
2010-02-24 00:34:39tejas81setnosy: + tejas81
messages: + msg99981
2009-05-30 06:16:15loewissetstatus: open -> closed
resolution: fixed
messages: + msg88564
2009-05-29 22:55:24benjamin.petersonsetmessages: + msg88548
2009-05-29 22:52:33loewissetmessages: + msg88547
2009-05-29 20:31:56benjamin.petersonsetmessages: + msg88532
2009-05-29 20:20:05r.david.murraysetversions: + Python 3.1
2009-05-29 19:29:58loewissetmessages: + msg88524
2009-05-29 18:44:59benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg88521
2009-05-29 17:29:05loewissetpriority: high -> release blocker
files: + wcsftime.diff
messages: + msg88518

keywords: + patch
2009-05-29 16:37:51loewislinkissue5562 superseder
2009-05-29 16:37:20loewislinkissue5903 superseder
2009-05-12 14:15:44ezio.melottisetnosy: + ezio.melotti
2009-05-05 22:31:18loewissetmessages: + msg87295
2009-05-02 14:53:08asmodaisetnosy: + asmodai
messages: + msg86949
2008-06-08 08:44:29georg.brandlcreate