$ 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.

This issue could be fixed using sync-time-timezone-attr-with-c.diff patch from http://bugs.python.org/issue22798

Isn't this a duplicate of #13466?

> Isn't this a duplicate of #13466?

In what way is it a duplicate?

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().

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.

Closing. See #22798 for the reasons why synchronizing C variables with the time module constants is not a solution.