public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Ken Brown <kbrown@cornell.edu>
To: cygwin@cygwin.com
Subject: Re: Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ
Date: Thu, 10 Jun 2021 10:57:35 -0400	[thread overview]
Message-ID: <0fcfeb54-53c5-b83d-bb13-e83a68eed469@cornell.edu> (raw)
In-Reply-To: <02d5b40f-aa35-f56c-5c5c-b10780355e91@SystematicSw.ab.ca>

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.

Ken

  reply	other threads:[~2021-06-10 14:59 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08 17:37 Keith Thompson
2021-06-09  3:43 ` Brian Inglis
2021-06-09 22:31 ` Keith Thompson
2021-06-10  2:36   ` Brian Inglis
2021-06-10 14:57     ` Ken Brown [this message]
2021-06-10 15:25       ` KAVALAGIOS Panagiotis (EEAS-EXT)
2021-06-10 18:31       ` Brian Inglis
2021-06-10 19:50         ` Ken Brown
2021-06-11  5:38           ` ASSI
2021-06-11 13:38             ` Ken Brown
2021-06-11 17:33           ` Brian Inglis
2021-06-11 18:05             ` Ken Brown
2021-06-12 16:34               ` Brian Inglis
2021-06-12 22:44                 ` Ken Brown
2021-06-11 10:51     ` Andrey Repin
  -- strict thread matches above, loose matches on Subject: below --
2021-06-07  6:59 Mike Kaganski
2021-06-08  4:34 ` Russell VT
2021-06-08  7:51   ` Mike Kaganski
2021-06-08 11:37 ` L A Walsh
2021-06-08 12:28   ` Mike Kaganski
2021-06-08 13:04     ` L A Walsh
2021-06-08 13:30       ` Mike Kaganski
2021-06-08 13:57         ` L A Walsh
2021-06-08 14:10           ` Mike Kaganski
2021-06-08 14:15             ` L A Walsh
2021-06-08 13:36       ` Mike Kaganski
2021-06-08 20:03       ` Mike Kaganski
2021-06-09  5:50         ` Brian Inglis
2021-06-11  6:01   ` Mike Kaganski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0fcfeb54-53c5-b83d-bb13-e83a68eed469@cornell.edu \
    --to=kbrown@cornell.edu \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).