[issue43649] time.strftime('%z') doesn't return UTC offset in the form ±HHMM
New submission from Patrick Storz <Eduard.Braun2@gmx.de>: This is a follow-up to https://bugs.python.org/issue20010 I'm seeing this very issue in a recent gcc build of Python 3.8 (mingw-w64-x86_64-python 3.8.8-2 from MSYS2 project): Python 3.8.8 (default, Feb 20 2021, 07:16:03) [GCC 10.2.0 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import time time.strftime('%z', time.localtime(time.time())) 'Mitteleuropäische Sommerzeit' time.strftime('%Z', time.localtime(time.time())) 'Mitteleuropäische Sommerzeit'
If this is indeed fixed in MSVCRT, it seems behavior is still not guaranteed when compiling with mingw-w64 gcc. ---------- components: Library (Lib), Windows messages: 389641 nosy: Aaron.Meurer, Ede123, Václav Dvořák, civalin, docs@python, eryksun, ezio.melotti, kepkin, martin-t, paul.moore, r.david.murray, steve.dower, tim.golden, vstinner, zach.ware priority: normal severity: normal status: open title: time.strftime('%z') doesn't return UTC offset in the form ±HHMM type: behavior versions: Python 3.8 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue43649> _______________________________________
Change by Patrick Storz <Eduard.Braun2@gmx.de>: _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue43649> _______________________________________
Eryk Sun <eryksun@gmail.com> added the comment: I closed bpo-20010 because the official PSF distributions of Python 3.5+ for Windows use the Universal CRT (ucrt), the system C runtime library for applications. ucrt does not have this problem with the "%z" format code. For example, using ctypes: >>> import ctypes >>> timeptr = (ctypes.c_int * 9)() >>> dest = (ctypes.c_char * 100)() >>> ucrt = ctypes.CDLL('ucrtbase', use_errno=True) >>> ucrt.strftime(dest, 100, b"%z", timeptr) 5 >>> dest.value b'+0100' Mingw-w64 probably links against msvcrt.dll, the private CRT that's used by some system components. For example: >>> msvcrt = ctypes.CDLL('msvcrt', use_errno=True) >>> msvcrt.strftime(dest, 100, b"%z", timeptr) 22 >>> dest.value b'Mitteleurop\xe4ische Zeit' This a third-party problem since Python is simply calling C strftime(). I'll leave this open for a core developer to consider, but I don't think a workaround is likely at this level. IIRC, compiling Python with Mingw-w64 requires extensive patching, so a workaround is more likely to be applied at that level. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue43649> _______________________________________
Steve Dower <steve.dower@python.org> added the comment: I agree with Eryk, this is not an issue with the supported C runtime. mingw-w64 has supposedly been working on UCRT support (it may even be working already?), and that is what will be necessary. We certainly aren't going to try and runtime detect this and reimplement it in the stdlib. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue43649> _______________________________________
participants (3)
-
Eryk Sun -
Patrick Storz
-
Steve Dower