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

[Ken Brown <kbrown@cornell.edu>]

On 6/12/2021 12:34 PM, Brian Inglis wrote:
> 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 https://bugs.python.org/issue44352.
>>>>>>>>>
>>>>>>>>> See Keith Thompson subthread and my reply with suggested fix:
>>>>>>>>>
>>>>>>>>> https://cygwin.com/pipermail/cygwin/2021-June/248692.html
>>>>>>>>>
>>>>>>>>> Windows does not recognize zoneinfo time zone identifiers in TZ only
>>>>>>>>> base format POSIX TZ strings with three alphabetic character identifiers:
>>>>>>>>>
>>>>>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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:
>>>>>>>>>
>>>>>>>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#bottom 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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:
>>>>>>>
>>>>>>>      https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-160 
>>>>>>>
>>>>>>>
>>>>>>> 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:
>>>>>>>
>>>>>>>      https://sourceware.org/git/?p=newlib-cygwin.git;f=winsup/cygwin/environ.cc;a=blob 
>>>>>>>
>>>>>>>
>>>>>>> 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:
>>>>>>
>>>>>>    https://cygwin.com/pipermail/cygwin/2017-May/232675.html .
>>>>>>
>>>>>> 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:
> 
>      https://sourceware.org/pipermail/cygwin/2012-January/199548.html
> 
> 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.
 > [...]

You obviously know much more about this than I do.  I'm going to drop out of 
this discussion and leave it to people who know what they're talking about.

Ken