Martin v. Löwis added the comment:
This is now fixed in r57720.
Using wide APIs would be possible through GetTimeZoneInformation,
however, then TZ won't be supported anymore (unless the CRT code to
parse TZ is duplicated).
--
nosy: +loewis
resolution: - fixed
status: open - closed
Changes by Martin v. Löwis:
--
assignee: - loewis
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1040
__
___
Python-bugs-list mailing list
Unsubscribe:
Amaury Forgeot d'Arc added the comment:
I have a patch for this, which uses MBCS conversion instead of relying
on the default utf-8 (here and several other places). Tested on a French
version of winXP.
Which leads me to the question: should Windows use MBCS encoding by
default when converting
Thomas Heller added the comment:
IMO the very best would be to avoid as many conversions as possible by
using the wide apis on Windows. Not for _tzname maybe, but for env
vars, sys.argv, sys.path, and so on. Not that I would have time to work
on that...
__
Thomas Heller added the comment:
BTW, setting the environment variable TZ to, say, 'GMT' makes the
problem go away.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1040
__
___
New submission from Thomas Heller:
In my german version of winXP SP2, python3 cannot import the time module:
c:\svn\py3k\PCbuildpython_d
Python 3.0x (py3k:57600M, Aug 28 2007, 07:58:23) [MSC v.1310 32 bit
(Intel)] on win32
Type help, copyright, credits or license for more information.
import
