From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin@cygwin.com
Subject: Re: Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ
Date: Wed, 9 Jun 2021 20:36:48 -0600 [thread overview]
Message-ID: <02d5b40f-aa35-f56c-5c5c-b10780355e91@SystematicSw.ab.ca> (raw)
In-Reply-To: <CAAHpriOJ5EZ0YzXjNOV-fydCb6bWHmPKiFZUC7KtFAi8DnkkDQ@mail.gmail.com>
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 am one of those folks who like maximum POSIX/Linux compatibility from
my environment and scripts, so maintain files/sym-/links like /run,
/etc/timezone, /etc/localtime from local 0p_/zp_ postinstall scripts.]
--
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.]
next prev parent reply other threads:[~2021-06-10 2:36 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 [this message]
2021-06-10 14:57 ` Ken Brown
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=02d5b40f-aa35-f56c-5c5c-b10780355e91@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--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).