DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A0C70384B110
Subject: Re: Python for Windows reports wrong local time when run under Cygwin
 on Europe/Moscow TZ
To: L A Walsh <cygwin@tlinx.org>, "cygwin@cygwin.com" <cygwin@cygwin.com>
References: <5542c19d-8b1a-1f28-2003-fe9493ee9b56@mail.ru>
 <60BF5677.9060904@tlinx.org>
Message-ID: <3aceb09c-98c4-0bed-d0a2-76bb9eabdccf@mail.ru>
Date: Fri, 11 Jun 2021 09:01:10 +0300
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: <60BF5677.9060904@tlinx.org>
Content-Language: en-US
Precedence: list
From: Mike Kaganski via Cygwin <cygwin@cygwin.com>
Reply-To: Mike Kaganski <mikekaganski@mail.ru>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>

On 08.06.2021 14:37, L A Walsh wrote:
> On 2021/06/06 23:59, Mike Kaganski via Cygwin wrote:
>> Hello,
>>
>> Running Cygwin 3.1.7-1 on Windows 10 Version 21H1 (OS Build 
>> 19043.985), I have this issue:
>>
>> when I start Cygwin's Python, I have correct time reported:
>>
>> But running Python for Windows (it doesn't matter which, specifically 
>> for the test I used the one from MS Store [1]), I have incorrect 
>> local time
>
> ...
>
> Though as to why -- likely the windows version is getting time zone
> clues + correction from BOTH cygwin and Windows, like it's told its
> in a TZ that is at 1 time, while Windows feeds it other data that
> says it is 2 hours off from the default.

As described in Python's issue [1], the problem comes from passing a TZ 
environment variable value that is invalid for Windows C runtime [2]. So 
in the end, it *might* be something for Cygwin to handle.

*If* Cygwin can detect that it starts a native Windows binary (I hope it 
can), then it could try to convert the TZ from Unix kind to Windows 
kind. That way, it could become valid. Or at least it could be unset 
(but that is questionable).

Of course, I could overlook some possible drawbacks from this imagined 
fix, which could make it undesirable. Anyway, I have implemented a 
workaround in our project unsetting TZ before calling Python, and it's 
resolved for us.

Thanks!


[1] https://bugs.python.org/issue44352

[2] 
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-160


-- 

Best regards,

Mike Kaganski


-- 
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