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.

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.

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.