Mail Archives: cygwin/2021/06/11/13:34:48
X-Recipient: | archive-cygwin AT delorie DOT com
|
X-Original-To: | cygwin AT cygwin DOT com
|
Delivered-To: | cygwin AT cygwin DOT com
|
DMARC-Filter: | OpenDMARC Filter v1.4.1 sourceware.org A652A3AAB4A9
|
Authentication-Results: | sourceware.org; dmarc=none (p=none dis=none)
|
| header.from=SystematicSw.ab.ca
|
Authentication-Results: | sourceware.org;
|
| spf=none smtp.mailfrom=systematicsw.ab.ca
|
X-Authority-Analysis: | v=2.4 cv=H864f8Ui c=1 sm=1 tr=0 ts=60c39e53
|
| a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17
|
| a=IkcTkHD0fZMA:10 a=8AHkEIZyAAAA:8 a=w_pzkKWiAAAA:8 a=yMhMjlubAAAA:8
|
| a=uZvujYp8AAAA:8 a=CCpqsmhAAAAA:8 a=PSTlso2uABE1VbvDIEAA:9 a=QEXdDO2ut3YA:10
|
| a=otTE43H4AhkA:10 a=AomDDAB-fV4A:10 a=qH7zXGipjgEA:10
|
| a=sRI3_1zDfAgwuvI8zelB:22 a=SLzB8X_8jTLwj6mN0q5r:22 a=ul9cdbp4aOFLsgKbc677:22
|
To: | cygwin AT cygwin DOT com
|
References: | <CAAHpriO6A+6bLXt0Qe-xpdXT1CiLjk7=7G31cHBtnVJ0kXb2Eg AT mail DOT gmail DOT com>
|
| <CAAHpriOJ5EZ0YzXjNOV-fydCb6bWHmPKiFZUC7KtFAi8DnkkDQ AT mail DOT gmail DOT com>
|
| <02d5b40f-aa35-f56c-5c5c-b10780355e91 AT SystematicSw DOT ab DOT ca>
|
| <0fcfeb54-53c5-b83d-bb13-e83a68eed469 AT cornell DOT edu>
|
| <28d9253d-71f4-c265-2861-9a3b0667799b AT SystematicSw DOT ab DOT ca>
|
| <be106324-4371-a804-5ccc-dec22b37f4af AT cornell DOT edu>
|
From: | Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
|
Organization: | Systematic Software
|
Subject: | Re: Python for Windows reports wrong local time when run under Cygwin
|
| on Europe/Moscow TZ
|
Message-ID: | <de7f3163-74c0-f304-ee58-a12064864196@SystematicSw.ab.ca>
|
Date: | Fri, 11 Jun 2021 11:33:05 -0600
|
User-Agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
|
| Thunderbird/78.11.0
|
MIME-Version: | 1.0
|
In-Reply-To: | <be106324-4371-a804-5ccc-dec22b37f4af@cornell.edu>
|
X-CMAE-Envelope: | MS4xfPcqSP9mwpT+u8xGyN9kt/159gqbez5LXBMjA8GhqV+BJ2AKBBL2KlHVhHxLO0WsCWANrOTdG9lw1HjS7dvyZwESOP0VfzhRck6Y3Iz5q3bcCHff9Fnp
|
| Pm/haLQEnjV+mGwKvCdVSJ8sFYaDf0LmdmMw0OnFZzLKWL3CGaecH3P0XIS3LX63vTlPi9musAUp1CbwxSMZ98O/0dlWKqrNU/o=
|
X-Spam-Status: | No, score=-3486.5 required=5.0 tests=BAYES_00, BODY_8BITS,
|
| KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A,
|
| RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,
|
| RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE,
|
| 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 AT cygwin DOT com
|
X-Mailman-Version: | 2.1.29
|
List-Id: | General Cygwin discussions and problem reports <cygwin.cygwin.com>
|
List-Unsubscribe: | <https://cygwin.com/mailman/options/cygwin>,
|
| <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
|
List-Archive: | <https://cygwin.com/pipermail/cygwin/>
|
List-Post: | <mailto:cygwin AT cygwin DOT com>
|
List-Help: | <mailto:cygwin-request AT cygwin DOT com?subject=help>
|
List-Subscribe: | <https://cygwin.com/mailman/listinfo/cygwin>,
|
| <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
|
Reply-To: | cygwin AT cygwin DOT com
|
Errors-To: | cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
|
Sender: | "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
|
X-MIME-Autoconverted: | from base64 to 8bit by delorie.com id 15BHYmgA028689
|
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.
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.
How do you set or get useful local time on your systems?
On Debian I "sudo dpkg-reconfigure tzdata" to set America/Edmonton after
install, locale-gen a few en_?? locales, and localedef personal local
customizations to en_CA.
I can't remember what I may have done setting up other distros when I
tried them.
--
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.]
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
- Raw text -