Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ

Brian Inglis
Sat Jun 12 16:34:52 GMT 2021

On 2021-06-11 12:05, Ken Brown via Cygwin wrote:
> On 6/11/2021 1:33 PM, Brian Inglis wrote:
>> On 2021-06-10 13:50, Ken Brown via Cygwin wrote:
>>> On 6/10/2021 2:31 PM, Brian Inglis wrote:
>>>> On 2021-06-10 08:57, Ken Brown via Cygwin wrote:
>>>>> On 6/9/2021 10:36 PM, Brian Inglis wrote:
>>>>>> On 2021-06-09 16:31, Keith Thompson via Cygwin wrote:
>>>>>>> [Sorry if the threading is messed up.  I don't subscribe, so I'm
>>>>>>> constructing this message from the web interface.  It should at 
>>>>>>> least
>>>>>>> show up under the correct subject.]
>>>>>>> Brian Inglis wrote:
>>>>>>>> On 2021-06-08 14:03, Mike Kaganski via Cygwin wrote:
>>>>>>>>> On 08.06.2021 16:04, L A Walsh wrote:
>>>>>>>>>> You might ask on a python list if anyone else has experienced
>>>>>>>>>> something similar with python or any other program.  I'm 
>>>>>>>>>> fairly sure
>>>>>>>>>> that neither MS nor cygwin design their OS with python in mind 
>>>>>>>>>> and
>>>>>>>>>> that it is python that is interacting funny when running under 
>>>>>>>>>> some
>>>>>>>>>> merge of both.  Have you asked the python people about this 
>>>>>>>>>> problem?
>>>>>>>>>> What did they suggest?
>>>>>>>>> FTR: filed
>>>>>>>> See Keith Thompson subthread and my reply with suggested fix:
>>>>>>>> Windows does not recognize zoneinfo time zone identifiers in TZ 
>>>>>>>> only
>>>>>>>> base format POSIX TZ strings with three alphabetic character 
>>>>>>>> identifiers:
>>>>>>>> That assumes US switch date "rules": for all years up to 
>>>>>>>> current, or
>>>>>>>> just DST, and whether pre- or post-2007 is unstated!
>>>>>>>> Otherwise it defaults to regional settings, used by Cygwin to 
>>>>>>>> map to
>>>>>>>> zoneinfo time zone identifiers, so if Python for Windows could 
>>>>>>>> clear TZ
>>>>>>>> before it is read by MSVCRT, it should DTRT.
>>>>>>>> Windows does not recognize expanded POSIX TZ format strings with <>
>>>>>>>> quoted alphanumeric characters, "-", "+", and start and end 
>>>>>>>> dates/times:
>>>>>>>> which make them usable outside of the US.
>>>>>>> Summary: IMHO Cygwin should adapt its default TZ setting to work
>>>>>>> with Windows.
>>>>>>> The suggestion is to modify Python for Windows so it can deal with
>>>>>>> the TZ format used by Cygwin.  I haven't used Python for Windows, 
>>>>>>> but
>>>>>>> as far as I know it's unrelated to Cygwin; rather it, like 
>>>>>>> Cygwin, is
>>>>>>> intended to work on top of Windows.  I'm not convinced it's 
>>>>>>> appropriate
>>>>>>> to ask Python for Windows to make a change purely for the sake of
>>>>>>> interoperating with Cygwin, which many PfW users presumably aren't
>>>>>>> even using.
>>>>>>> I've run into another application that has problems with Cygwin's
>>>>>>> settings of $TZ.  It was a internal test application that isn't
>>>>>>> going to change its timezone handling just for this problem.
>>>>>>> The ideal solution would be for Windows to recognize TZ values like
>>>>>>> "America/Los_Angeles", but that's not likely to happen any time 
>>>>>>> soon.
>>>>>>> My suggestion, since Cygwin is supposed to interoperate with 
>>>>>>> Windows,
>>>>>>> is one of the following:
>>>>>>> - Cygwin should avoid setting TZ to a value that Windows doesn't 
>>>>>>> recognize
>>>>>>>    (if I set TZ=PST8PDT, everything seems to work correctly); OR
>>>>>>> - Cygwin shouldn't set TZ at all by default.  (I've updated my
>>>>>>>    $HOME/.bash_profile on Cygwin to unset TZ, and Cygwin commands 
>>>>>>> seem
>>>>>>>    to work correctly with TZ unset); OR
>>>>>>> - Cygwin, when invoking a non-Cygwin executable, should first either
>>>>>>>    unset TZ or translate it to a format that Windows will recognize.
>>>>>>>    I have no idea how difficult that would be.
>>>>>> Impossible to set Windows TZ usefully as it obeys unstated US DST 
>>>>>> rules (like posixrules, perhaps 2007+?), and may have limits on 
>>>>>> hour offset magnitudes.
>>>>>> MS libraries are stuck at POSIX 1996 and C 99 subset 
>>>>>> compatibility, but non-standard-conformant including which headers 
>>>>>> contain definitions:
>>>>>> It may be possible to unset TZ when running non-Cygwin programs 
>>>>>> (possibly behind a CYGWIN env var setting e.g. winnotz) by adding 
>>>>>> TZ= to conv_envvars, and writing new helper functions 
>>>>>> env_tz_to_posix to call tzset and env_tz_to_win32 to remove TZ in:
>>>>>> What is the opinion on this from both Windows users and Cygwin 
>>>>>> patchers?
>>>>> I'm not convinced it's worth the trouble.  I haven't seen anyone 
>>>>> argue that it's useful for Cygwin to set TZ, and I have seen an 
>>>>> argument that it's harmful:
>>>>> .
>>>>> So I prefer Keith's second suggestion:
>>>>>  >> - Cygwin shouldn't set TZ at all by default.
>>>> It does so in default startup scripts
>>> Right, and I'm agreeing with Bruno (in the message cited above) that 
>>> the default startup scripts should stop doing that.
>>>> to get the correct behaviour from Cygwin DLL and programs,
>>> Can you be more specific?  What goes wrong if TZ is not set?  I 
>>> haven't seen any POSIX or Linux documentation that says it should be 
>>> set, and I've just checked on two different Linux distros that it's 
>>> not set by default.

See original message:

Looks like the tzdb metadata is not fully populated, including zone 
abbreviations, though that could be patched to use <%z> like tzdata 
defaults where countries use only a single local time zone and no name 
(other than COUNTRY time, and maybe Winter Time or Summer Time, as in 
many European countries).

>> I would expect that date, ls, etc. would output UTC, or perhaps PST or 
>> EST, depending on tzdata builds of Factory (tz -00/unset) and 
>> posixrules (Cygwin PST, Debian EST) and use during system setup and 
>> startup, unless /etc/timezone and/or /etc/localtime are set, and used 
>> during startup, often by systemd, or login by profiles.
> No, you can 'unset TZ' and everything works fine.  Try it yourself.

It works incorrectly before 2007 because of DST rule changes.
Cygwin effectively uses expanded POSIX rules with a single pair of 
transition dates, applied to all years.
Doesn't work for anything other than current time rules, as Cygwin 
doesn't (yet?) use historical "Dynamic" DST.
"Dynamic" DST was probably only added to Vista about 2006 because the US 
was changing rules in 2007.

See comments by MS TZ/DST blogger, commentator, and tzdb contributor 
Matt Johnson-Pint:

where he suggest the poster uses tzdb instead of trying to fix Windows 
Dynamic DST rules!
[I could generate equivalent Windows Dynamic DST reg entries from tzdb, 
but tzdb allows relational holiday calendar rules like "May Mon<25" - 
the Monday before the 25th May (Victoria Day, CA which mostly coincides 
with Memorial Day, US), and generates up to 400 years of entries, which 
I don't think the registry would cope with too well!]

For Windows TZ updates see:

Support for rule changes from 2010:

As a result, it does not have much in the way of history for times past 
(see links above and examples below), unlike the tzdb in tzdata package, 
which has full history back to 1970, and in some cases, back to before 
standard time (Local Mean Time); if you have the tzcode package 
installed, try zdump with your local time zone e.g.:

	$ zdump -Vc1800,2008 America/New_York

or use -Vc1800,2022 in other countries with more recent changes.

Many zones in the Middle East have up to four changes each year if  DST 
would be in effect during Ramadan (it is reverted temporarily during 
that month), and there are many recent rule changes in most other 
countries, even Europe where countries jumped around annually until they 
joined or decided to conform with the EU, similar to Canadian provinces 
and Mexican states deciding to conform with the US from 2007, although 
some zones in both countries changed their minds after that, and some 
dropped DST e.g. Yukon CA in 2020!)

 From MS comments about Ramadan not appearing in TZ history, with the 
implication that MS have kludged current timekeeping to handle a DST 
reversion, but may be unable to handle more than one transition a year, 
historical file timestamps from earlier in the year will be displayed 

MS are issuing historical corrections for previous years for Windows 10, 
but it looks like earlier Windows versions are getting more outdated:

>> How do you set or get useful local time on your systems?
> Cygwin takes care of it.  If TZ is unset, Cygwin queries Windows via 
> GetTimeZoneInformation.  See tzgetwintzi in 
> winsup/cygwin/tzcode/localtime_wrapper.c.

I was asking about your Linux/BSD systems.

[Dump of Windows tz info for my tz (from Cygwin regtool as it converts 
to decimal but does not dump REG_BINARY keys in full only the first 
eight bytes, and Windows reg to dump REG_BINARY keys in full):

Bias (REG_DWORD) = 0x000001a4 (420)
DaylightBias (REG_DWORD) = 0xffffffc4 (4294967236)
DaylightName (REG_SZ) = "@tzres.dll,-191"
DaylightStart (REG_BINARY) = 00 00 03 00 02 00 02 00
DynamicDaylightTimeDisabled (REG_DWORD) = 0x00000000 (0)
RealTimeIsUniversal (REG_DWORD) = 0x00000001 (1)
StandardBias (REG_DWORD) = 0x00000000 (0)
StandardName (REG_SZ) = "@tzres.dll,-192"
StandardStart (REG_BINARY) = 00 00 0b 00 01 00 02 00
TimeZoneKeyName (REG_SZ) = "Mountain Standard Time"

     Bias    REG_DWORD    0x1a4
     DaylightBias    REG_DWORD    0xffffffc4
     DaylightName    REG_SZ    @tzres.dll,-191
     DaylightStart    REG_BINARY    00000300020002000000000000000000
     DynamicDaylightTimeDisabled    REG_DWORD    0x0
     RealTimeIsUniversal    REG_DWORD    0x1
     StandardBias    REG_DWORD    0x0
     StandardName    REG_SZ    @tzres.dll,-192
     StandardStart    REG_BINARY    00000B00010002000000000000000000
     TimeZoneKeyName    REG_SZ    Mountain Standard Time

HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Time Zones/Mountain 
Standard Time
Dynamic DST\ ()
Display (REG_SZ) = "(UTC-07:00) Mountain Time (US & Canada)"
Dlt (REG_SZ) = "Mountain Summer Time"
MUI_Display (REG_SZ) = "@tzres.dll,-190"
MUI_Dlt (REG_SZ) = "@tzres.dll,-191"
MUI_Std (REG_SZ) = "@tzres.dll,-192"
Std (REG_SZ) = "Mountain Standard Time"
TZI (REG_BINARY) = a4 01 00 00 00 00 00 00

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Mountain Standard Time
     Display    REG_SZ    (UTC-07:00) Mountain Time (US & Canada)
     Dlt    REG_SZ    Mountain Summer Time
     MUI_Display    REG_SZ    @tzres.dll,-190
     MUI_Dlt    REG_SZ    @tzres.dll,-191
     MUI_Std    REG_SZ    @tzres.dll,-192
     Std    REG_SZ    Mountain Standard Time

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Mountain Standard Time\Dynamic DST
     2006    REG_BINARY 
     2007    REG_BINARY 
     FirstEntry    REG_DWORD    0x7d6
     LastEntry    REG_DWORD    0x7d7

HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Time Zones/Mountain 
Standard Time/Dynamic DST
2006 (REG_BINARY) = a4 01 00 00 00 00 00 00
2007 (REG_BINARY) = a4 01 00 00 00 00 00 00
FirstEntry (REG_DWORD) = 0x000007d6 (2006)
LastEntry (REG_DWORD) = 0x000007d7 (2007)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Mountain Standard Time\Dynamic DST
     2006    REG_BINARY 
     2007    REG_BINARY 
     FirstEntry    REG_DWORD    0x7d6
     LastEntry    REG_DWORD    0x7d7

# dump of Morocco Dynamic DST
$ reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Morocco Standard Time\Dynamic DST" /s

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time 
Zones\Morocco Standard Time\Dynamic DST
     2007    REG_BINARY 
     2008    REG_BINARY 
     2009    REG_BINARY 
     2010    REG_BINARY 
     2011    REG_BINARY 
     2012    REG_BINARY 
     2013    REG_BINARY 
     2014    REG_BINARY 
     2015    REG_BINARY 
     2016    REG_BINARY 
     2017    REG_BINARY 
     FirstEntry    REG_DWORD    0x7d7
     LastEntry    REG_DWORD    0x7ed
     2020    REG_BINARY 
     2021    REG_BINARY 
     2022    REG_BINARY 
     2023    REG_BINARY 
     2024    REG_BINARY 
     2025    REG_BINARY 
     2026    REG_BINARY 
     2027    REG_BINARY 
     2028    REG_BINARY 
     2029    REG_BINARY 
     2018    REG_BINARY 
     2019    REG_BINARY 

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

More information about the Cygwin mailing list