Title: time.strftime('%z') doesn't return UTC offset in the form ±HHMM
Type: behavior Stage: resolved
Components: Library (Lib), Windows Versions: Python 3.8
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: Aaron.Meurer, Václav Dvořák, civalin, docs@python, ede123, eryksun, ezio.melotti, kepkin, martin-t, paul.moore, r.david.murray, steve.dower, tim.golden, vstinner, zach.ware
Priority: normal Keywords:

Created on 2021-03-28 18:23 by ede123, last changed 2021-04-23 21:51 by steve.dower. This issue is now closed.

Messages (3)
msg389641 - (view) Author: Patrick Storz (ede123) Date: 2021-03-28 18:23
This is a follow-up to

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.
msg389645 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2021-03-28 19:24
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)
    >>> dest.value

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)
    >>> 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.
msg391744 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2021-04-23 21:51
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.
Date User Action Args
2021-04-23 21:51:17steve.dowersetstatus: open -> closed
resolution: third party
messages: + msg391744

stage: resolved
2021-03-28 19:24:26eryksunsetmessages: + msg389645
2021-03-28 18:23:58ede123setnosy: paul.moore, vstinner, tim.golden, ezio.melotti, r.david.murray, Aaron.Meurer, docs@python, zach.ware, eryksun, steve.dower, civalin, kepkin, martin-t, Václav Dvořák, ede123
2021-03-28 18:23:17ede123create