STINNER Victor added the comment:
"Instead of trying to bet what is the correct encoding, it would be simpler
(and safer) to read the Unicode version of the tzname array: StandardName and
DaylightName of GetTimeZoneInformation()."
GetTimeZoneInformation() formats correctly timezone names, but it reintroduces
#10653 issue: time.strftime("%Z") formats the timezone name differently.
See also issue #13029 which is a duplicate of #10653, but contains useful
information.
--
Example on Windows 7 with a french setup configured to Tokyo's timezone.
Using GetTimeZoneInformation(), time.tzname is ("Tokyo", "Tokyo (heure
d\u2019\xe9t\xe9)"). U+2019 is the "RIGHT SINGLE QUOTATION MARK". This
character is usually replaced with U+0027 (APOSTROPHE) in ASCII.
time.strftime("%Z") gives "Tokyo (heure d'\x81\x66ete)" (if it is implemented
using strftime() or wcsftime()).
--
If I understood correctly, Python 3.3 has two issues on Windows:
* time.tzname is decoded from the wrong encoding
* time.strftime("%Z") gives an invalid output
The real blocker issue is a bug in strftime() and wcsftime() in Windows CRT. A
solution is to replace "%Z" with the timezone name before calling strftime() or
wcsftime(), aka working around the Windows CRT bug.
----------
nosy: +ocean-city
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16322>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
