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

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

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: <>
2021-06-08 19:05:21mikekaganskilinkissue44352 messages
2021-06-08 19:05:21mikekaganskicreate