From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward106j.mail.yandex.net (forward106j.mail.yandex.net [5.45.198.249]) by sourceware.org (Postfix) with ESMTPS id F3A34383B42C for ; Fri, 11 Jun 2021 11:05:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F3A34383B42C Received: from iva3-509fc3649d15.qloud-c.yandex.net (iva3-509fc3649d15.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:4982:0:640:509f:c364]) by forward106j.mail.yandex.net (Yandex) with ESMTP id 1EC6711A1E91 for ; Fri, 11 Jun 2021 14:05:02 +0300 (MSK) Received: from iva4-b3ebd202b141.qloud-c.yandex.net (iva4-b3ebd202b141.qloud-c.yandex.net [2a02:6b8:c0c:4e8e:0:640:b3eb:d202]) by iva3-509fc3649d15.qloud-c.yandex.net (mxback/Yandex) with ESMTP id VdaGezK077-51IeQ2Op; Fri, 11 Jun 2021 14:05:02 +0300 Received: by iva4-b3ebd202b141.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id nIkxiXgAec-512aIimF; Fri, 11 Jun 2021 14:05:01 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Received: from [192.168.1.10] (HELO daemon2.darkdragon.lan) by daemon2 (Office Mail Server 0.8.12 build 08053101) with SMTP; Fri, 11 Jun 2021 10:51:00 -0000 Date: Fri, 11 Jun 2021 13:51:00 +0300 From: Andrey Repin X-Mailer: The Bat! (v6.8.8) Home Reply-To: cygwin@cygwin.com X-Priority: 3 (Normal) Message-ID: <198658094.20210611135100@yandex.ru> To: Brian Inglis , cygwin@cygwin.com Subject: Re: Python for Windows reports wrong local time when run under Cygwin on Europe/Moscow TZ In-Reply-To: <02d5b40f-aa35-f56c-5c5c-b10780355e91@SystematicSw.ab.ca> References: <02d5b40f-aa35-f56c-5c5c-b10780355e91@SystematicSw.ab.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_THEBAT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 11:05:06 -0000 Greetings, Brian Inglis! > 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.] You can always reply to your own message sent to the list in an appropriate thread. Nobody's linking by subject, that was frowned upon 25 years ago, and just ridiculous in XXI century. >> >> 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. Windows programs generally ignore TZ env var at all to begin with. >> 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 would wish to avoid unexpected environment modification. If anything, when you want to frequently call Windows programs from within Cygwin, you could always create symlink or an appropriate wrapper in /usr/local/bin. I.e. $ ls -ld /usr/local/bin/* | cut -f 7- /usr/local/bin/adb -> /c/Programs/MyPhoneExplorer/DLL/adb.exe /usr/local/bin/chcp -> /c/Windows/System32/chcp.com (since Cygwin magic only works with .exe) /usr/local/bin/git-agent.sh (force read of ssh-agent settings before calling git) /usr/local/bin/ip (*NIX compatibility wrapper around netsh) /usr/local/bin/meld -> /c/Program Files (x86)/Meld/Meld.exe /usr/local/bin/svn1.6 -> /c/Programs/Subversion/bin/svn.exe /usr/local/bin/tasklist /usr/local/bin/tcc (wrapper around TakeCommandConsole) /usr/local/bin/vscode -> /c/Program Files/Microsoft VS Code/bin/code (vendor-provided wrapper) > [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.] If TZ is not all-useful for Cygwin, I would vote to not have it set at all. -- With best regards, Andrey Repin Friday, June 11, 2021 12:22:26 Sorry for my terrible english...