Issue 22799: wrong time.timezone - Python tracker (original) (raw)

Created on 2014-11-05 15:00 by akira, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (7)
msg230684 - (view)	Author: Akira Li (akira) *	Date: 2014-11-05 15:00
$ TZ=:Europe/Moscow ./python -mtest -v test_time ====================================================================== FAIL: test_localtime_timezone (test.test_time.TestPytime) ---------------------------------------------------------------------- Traceback (most recent call last): File ".../Lib/test/test_time.py", line 721, in test_localtime_timezone self.assertEqual(lt.tm_gmtoff, -[time.timezone, time.altzone][lt.tm_isdst]) AssertionError: 10800 != 14400 ---------------------------------------------------------------------- Ran 45 tests in 1.832s FAILED (failures=1, skipped=3) test test_time failed 1 test failed: test_time UTC offset had changed on 2014-10-26 in Europe/Moscow timezone from MSK+0400 to MSK+0300. Python time.timezone returns -14400 (old utc offset) despite C timezone variable having the correct value (Python uses tm_gmtoff from Jan here). Similar case where timezone, altzone may be wrong http://bugs.python.org/msg31138 The issue again http://bugs.python.org/issue22798 is that time timezone attribute is out-of-sync with the corresponding C variable i.e., C library provides correct values but time module doesn't use them.
msg231754 - (view)	Author: Akira Li (akira) *	Date: 2014-11-27 10:03
This issue could be fixed using sync-time-timezone-attr-with-c.diff patch from http://bugs.python.org/issue22798
msg234893 - (view)	Author: Alexander Belopolsky (belopolsky) *	Date: 2015-01-28 13:43
Isn't this a duplicate of #13466?
msg234901 - (view)	Author: Akira Li (akira) *	Date: 2015-01-28 16:17
> Isn't this a duplicate of #13466? In what way is it a duplicate?
msg234905 - (view)	Author: Alexander Belopolsky (belopolsky) *	Date: 2015-01-28 18:00
Please take a look at . I agree with MAL that time module globals timezone and daylight should be deprecated in favor of tm_gmtoff or datetime.astimezone().
msg234907 - (view)	Author: Akira Li (akira) *	Date: 2015-01-28 18:55
I agree that time.timezone, time.altzone is not enough in the general case. Because UTC offset may be different at different dates for reasons unrelated to DST transitions therefore any solution that doesn't take into account a given date/time into account will fail. *Nothing* works in the general case. Nothing. But it doesn't mean that the current behaviour of time.timezone can't be improved for this particular use-case: lt = time.localtime() # in a short-lived script assertEqual(lt.tm_gmtoff, -[time.timezone, time.altzone][lt.tm_isdst]) The test checks values for the current time (time.localtime()). It should work in *most* cases if time.timezone/altzone have correct values at import time. Perhaps synchronizing time.timezone with C timezone variable as I've mentioned before http://bugs.python.org/issue22798 may fix this issue too.
msg276476 - (view)	Author: Alexander Belopolsky (belopolsky) *	Date: 2016-09-14 19:08
Closing. See #22798 for the reasons why synchronizing C variables with the time module constants is not a solution.