Author mikekaganski
Recipients mikekaganski, paul.moore, steve.dower, tim.golden, zach.ware
Date 2021-06-08.19:05:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1623179121.82.0.0104763138056.issue44352@roundup.psfhosted.org>
In-reply-to
Content
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
History
Date User Action Args
2021-06-08 19:05:21mikekaganskisetrecipients: + mikekaganski, paul.moore, tim.golden, zach.ware, steve.dower
2021-06-08 19:05:21mikekaganskisetmessageid: <1623179121.82.0.0104763138056.issue44352@roundup.psfhosted.org>
2021-06-08 19:05:21mikekaganskilinkissue44352 messages
2021-06-08 19:05:21mikekaganskicreate