MinGW/MSys 2 doesn't seem to recognize TZ environment variable

I work on a legacy system originally written in C for 3b2 SVR3, later in C++ for Sun/Solaris, now mainly for Linux. We have a few users who require our apps to run on Windows Servers, so we have accommodated that for the last 18 years using MSys / MinGW, cross compiled from our *nix-based development machines. We're now trying to upgrade to MSys 2 and have run into what appears to be an intractable problem that no amount of searching has turned up an answer to. Our application works across multiple time zones simultaneously. We can't rely on a static system time zone setting to operate properly. We get our time zone definitions from the IANA database, installed as zoneinfo files in the traditional locations, depending upon environment. We update zoneinfo for our users as the need arises. For as long as I can remember (I've worked on this for nearly 30 years), it was adequate to putenv("TZ="); tzset(); to get methods like mktime() and localtime() to produce the information we needed. That has stopped working now that we've moved to MSys 2. Additionally, most of our code doesn't care what the initial time zone is, but one method insists that the TZ variable have some value (any value, it doesn't care). It really doesn't matter why TZ must be set - that code exposes another symptom that we might not otherwise have noticed so quickly: upon entry to any of our programs, the TZ environment variable has been removed from the environment. The final curiosity is that MSys 2 comes with a **date** program that seems to work just fine with the TZ environment variable, as do **printenv** and **ls**, seeming to indicate that what we need to do *can* be done. We have a short test program we've been using to demonstrate the problem and with any luck, prove that we've found a solution: #include #include #include int main(int argc, const char *const *argv) { const char *tz = getenv("TZ"); const char *ptz = tz ? tz : "TZ not set"; printf("at entry: %s\n", ptz); time_t now = time(NULL); putenv("TZ=US/Pacific"); tzset(); printf("in %s it is now %s", getenv("TZ"), ctime(&now)); putenv("TZ=US/Eastern"); tzset(); printf("in %s it is now %s", getenv("TZ"), ctime(&now)); return 0; } When I run the above on our Linux dev machine, I get the following output: $ printenv TZ US/Central $ date "+%F %T %Z" 2024-08-15 10:20:55 CDT $ ./msystest at entry: US/Central in US/Pacific it is now Thu Aug 15 08:20:55 2024 in US/Eastern it is now Thu Aug 15 11:20:55 2024 Under MSys 2, just seconds later, I get the following: $ printenv TZ US/Central $ date "+%F %T %Z" 2024-08-15 10:20:57 CDT $ ./msystest at entry: TZ not set in US/Pacific it is now Thu Aug 15 16:20:57 2024 in US/Eastern it is now Thu Aug 15 16:20:57 2024 Using **ldd** on MSys 2, we've noticed that there are different DLLs referenced by **date** and **msystest**: $ ldd /usr/bin/date ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ff962d20000) KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ff961b30000) KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ff960340000) msys-intl-8.dll => /usr/bin/msys-intl-8.dll (0x430b30000) msys-2.0.dll => /usr/bin/msys-2.0.dll (0x180040000) msys-iconv-2.dll => /usr/bin/msys-iconv-2.dll (0x5603f0000) $ ldd msystest ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ff962d20000) KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ff961b30000) KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ff960340000) msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x7ff962790000) So our question is - is our problem the result of the differing DLLs, and if so, how do we get the msys DLLs built into our programs rather than the msvcrt DLL? We've done a lot of searching online to try to resolve this to little avail. We usually get 1 of 2 answers: 1. Windows doesn't work that way so you can't do what you want with MSys 2. This is how you build a DLL with MinGW Needless to say, the answers are either (1) wrong, or (2) answering the wrong question. Any help anyone can provide/point us to would be invaluable.