Eryk Sun <[email protected]> added the comment:
Update since msg255133:
Python 3.8+ now calls setlocale(LC_CTYPE, "") at startup in Windows, as 3.x has
always done in POSIX. So decoding the output of C strftime("%Z") with
PyUnicode_DecodeLocaleAndSize() 'works' again, since both default to the
process code page. The latter is usually the system code page, unless
overridden to UTF-8 in the application manifest.
But calling C strftime() as a workaround is still a fragile solution, since it
requires that the process code page is able to encode the process or thread UI
language. In general, the system code page, the current user locale, and
current user preferred language are independent settings in Windows.
Calling C strftime() also unnecessarily limits the format string to characters
in the current LC_CTYPE locale encoding, which requires hacky workarounds.
Starting with Windows 10 v2004 (build 19041), ucrt uses an internal
wide-character version of the time-zone name that gets returned by an internal
__wide_tzname() call and used for "%Z" in wcsftime(). The wide-character value
gets updated by _tzset() and kept in sync with _tzname.
If Python switched to using wcsftime() in Windows 10 2004+, then the current
locale encoding would no longer be a problem for any UI language.
Also, bpo-36779 switched to setting time.tzname by directly calling WinAPI
GetTimeZineInformation(). time.tzset() should be implemented in order to keep
the value of time.tzname in sync with time.strftime("%Z").
----------
components: +Extension Modules
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python
3.6
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue8304>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
