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.

Author eryksun
Recipients belopolsky, brian.curtin, eryksun, jkloth, ocean-city, pitrou, python-dev, vstinner
Date 2021-03-07.13:06:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1615122377.46.0.511695448962.issue10653@roundup.psfhosted.org>
In-reply-to
Content
> decoding the output of strftime("%Z") with PyUnicode_DecodeLocaleAndSize()
> works again since both agree on using the process active code page

At least it works as much as it ever did. It depends on the process active code page being compatible with the preferred UI language of the current process or thread. For example if the UI language is Japanese ('ja-JP') for the current user, but the process active code page is Latin 1252 (based on the system locale), then the result will be garbage. In that case, given the time-zone name is in Japanese, both LC_TIME and LC_CTYPE have to be changed to "ja-JP" in order to correctly encode (as tzname in ucrt), decode-encode (for strftime in ucrt) and finally decode again via PyUnicode_DecodeLocaleAndSize(). If Python switched back to using wcsftime() in Windows 10 2004+, then the current locale encoding would no longer be a problem for any UI language.
History
Date User Action Args
2021-03-07 13:06:17eryksunsetrecipients: + eryksun, belopolsky, pitrou, vstinner, ocean-city, jkloth, brian.curtin, python-dev
2021-03-07 13:06:17eryksunsetmessageid: <1615122377.46.0.511695448962.issue10653@roundup.psfhosted.org>
2021-03-07 13:06:17eryksunlinkissue10653 messages
2021-03-07 13:06:17eryksuncreate