Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ
Thu Jun 10 14:57:35 GMT 2021
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:
>>> 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.
More information about the Cygwin