C standard delegates to implementations:

  The local time zone and Daylight Saving Time are implementation-defined.

gcc (one of the implementations) says [1]:

  [timezone] contains the difference between UTC and the latest local standard time, in seconds west of UTC. 

Notice the word "latest". To be fair, gcc (the actual implementation) 
uses a weird logic to assign timezone, daylight values in Europe/Moscow 
timezone in 2011-2015.

Python own tests assume that time.timezone reflects the *current* 
(most recent) time http://bugs.python.org/issue22799

C tzname, timezone, daylight are not constants. They may change e.g., see 
http://bugs.python.org/issue22798 (the C code demonstrates that 
tzname changes even for the same local timezone).

POSIX specifies a profile (additional restrictions but no conflict) of C 
standard for the time functions e.g., tzset(), mktime() [2], ctime(), 
localtime() may change tzname, timezone, daylight (but *not* gmtime() or 
asctime()).

To summarize:

- timezone is implementation-defined in C
- gcc (one of implementations) says that timezone corresponds to 
  the latest time (the actual behavior is complicated)
- POSIX says that time functions shall set timezone info i.e., timezone 
  is not a constant (it is obvious due to tzset() existence)
- Python tests assume that timezone corresponds to the current time (not 
  january or july)

I'm not sure what time.timezone behaviour should be:

- leave it as is (unsynchronized with C values and it may be different
  from the current correct value) -- it makes time module unusable in
  some timezones (60% all time, 11% since 2001), some of the time
- use "latest" correct (gmtoff where available) value during importing
  the time module -- it would fix this issue22752
- synchronize with C values -- it improves some things e.g., it may fix
  http://bugs.python.org/issue22426 but it might make the behavior
  more platform dependent (tests needed) and it make things worse in some
  timezones e.g., where dst() != 1 hour (13% all time, 0.9% since 2000)


[1] http://www.gnu.org/software/libc/manual/html_node/Time-Zone-Functions.html

[2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html