[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

[Mike Kaganski]

Mike Kaganski  added the comment:

@Eryk Sun: yes, of course you are right - but please see the date of the 
commit; I didn't know what you kindly explained me in your reply yesterday :-) 
Thank you again.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

[Eryk Sun]

Eryk Sun  added the comment:

Note that this explanation in your commit is wrong and unhelpful: "likely 
because datetime.datetime.now in the native Windows Python takes into account 
both system timezone data and the TZ environment variable". When TZ is set, 
localtime() is based only on the TZ value, and daylight saving time uses only 
U.S. rules (e.g. beginning 2021-03-14 and ending 2021-11-07). The value must be 
of the form "tzn [+|-]hh[:mm[:ss] ][dzn]", but there is no validation. So 
"Europe/Moscow" is invalid and gets parsed as UTC with U.S. DST. I recommend 
clearing the TZ variable because the value format is non-standard, and its DST 
support is U.S.-centric nonsense.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

[Mike Kaganski]

Mike Kaganski  added the comment:

Thank you Eryk! This is a good workaround for me. I have implemented it: 
https://git.libreoffice.org/core/+/3bcaa4ba79477a21251ddaa06e0ea159196a7ffb

It looks like it's not a Python's problem; I suppose this may be closed. Thanks 
again!

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

[Eryk Sun]

Eryk Sun  added the comment:

> 2. Execute 'set TZ=Europe/Moscow'

The Windows C runtime supports a simple format for the TZ environment variable, 
which is detailed in the documentation of _tzset() [1]. For example, it's 
"MSK-3" for Moscow Standard Time. It's -3 because the offset is from local time 
to UTC. 

The CRT does not verify that the TZ value is valid. "Europe/Moscow" is invalid, 
but it's blindly parsed anyway. There's no UTC offset, so it defaults to UTC (0 
offset). It's parsed as supporting daylight saving time, according to U.S. 
rules. Currently this corresponds to UTC + 1. That's why there's a -2 hour 
delta from Moscow Standard Time, which does not observe daylight saving time.

I recommend that you unset the TZ environment variable before running Windows 
Python. Use the system timezone.

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

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

[Zachary Ware]

Change by Zachary Ware :


--
nosy: +belopolsky, p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44352] Native Windows Python builds running on Europe/Moscow TZ report wrong time from datetime.datetime.now when there is TZ environment variable also set to Europe/Moscow

[Mike Kaganski]

New submission from Mike Kaganski :

On a Windows 10 system, which TZ is set to Moscow (UTC+3), I use a native 
Windows Python build (as opposed to e.g. one from Cygwin). Specifically, I 
tested both custom Python build created by LibreOffice project, as well as the 
Python by Python Software Foundation available from MS Store [1].

1. Open command prompt on Windows (cmd.exe).
2. Execute 'set TZ=Europe/Moscow'
3. Execute 'python'
4. In the Python prompt, execute 'import datetime'
5. Execute 'datetime.datetime.now()'

The result of this is a time that is two hours off, e.g.

> datetime.datetime(2021, 6, 8, 19, 59, 21, 925240)

instead of proper

> datetime.datetime(2021, 6, 8, 21, 59, 21, 925240)

which appears when step #2 is skipped.
Possibly Python takes both system time zone information *and* the environment 
variable into account when calculating the time. I suppose it should only 
consider one or the other, not both.

Note that the problem does not happen with Cygwin's Python, which works fine 
with the same TZ environment variable value.

For a real-life problem that results from this, see case at [2], where unit 
test is failing only from 00:00 till 02:00 on my local system, obviously 
telling me that I should sleep at that time, not try to run unit tests :-)

[1] https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l
[2] 
https://gerrit.libreoffice.org/c/core/+/92217/2#message-f55091795e7cde9d75adc00ddb69451121b644f6

--
components: Windows
messages: 395355
nosy: mikekaganski, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Native Windows Python builds running on Europe/Moscow TZ report wrong 
time from datetime.datetime.now when there is TZ environment variable also set 
to Europe/Moscow
type: behavior
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com