Title: wrong time.timezone
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.6, Python 3.4, Python 3.5
Status: closed Resolution: wont fix
Dependencies: Superseder: Document time module constants (timezone, tzname, etc.) as deprecated.
View: 28157
Assigned To: Nosy List: akira, belopolsky
Priority: normal Keywords:

Created on 2014-11-05 15:00 by akira, last changed 2016-09-14 19:17 by belopolsky. 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/", 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:

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

The issue again 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
msg234893 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) 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) * (Python committer) Date: 2015-01-28 18:00
Please take a look at msg148208.  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 may fix this issue
msg276476 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) 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.
Date User Action Args
2016-09-14 19:17:21belopolskysetsuperseder: Document time module constants (timezone, tzname, etc.) as deprecated.
2016-09-14 19:08:31belopolskysetstatus: open -> closed
resolution: wont fix
messages: + msg276476
2015-01-28 18:55:49akirasetmessages: + msg234907
2015-01-28 18:00:00belopolskysetmessages: + msg234905
2015-01-28 16:17:22akirasetmessages: + msg234901
2015-01-28 13:43:22belopolskysetmessages: + msg234893
2015-01-28 13:41:08belopolskysetnosy: + belopolsky
2014-11-27 10:03:24akirasetmessages: + msg231754
2014-11-05 15:00:06akiracreate