There was timezone change in Russia at 26 october (http://www.timeanddate.com/time/change/russia/moscow)

But code in timemodule.c using first day of the year to get timezone
 
        t = (time((time_t *)0) / YEAR) * YEAR;
        p = localtime(&t);
        janzone = -p->tm_gmtoff;

so janzone have incorrect value (with old timezone)

$ date -R    
Tue, 28 Oct 2014 17:27:54 +0300

$ python -c "import time; print time.timezone"
-14400

The time module cannot handle historical changes in timezone info.  Try using datetime.datetime.astimezone() method (with no arguments) or a 3rd party timezone support library.

https://docs.python.org/3/library/datetime.html#datetime.datetime.astimezone

Is it possible to set timezone based on localtime(current_time) where current_time is the result of time() call?

This bug is not just about returning the wrong timezone. Because of it, the full time string produced with Python may be wrong. For example, my mail sending program uses `email.utils.formatdate(localtime=True)', and that is returning a time one hour in the past currently.

> Is it possible to set timezone based on localtime(current_time) where current_time is the result of time() call?

No. time.timezone is a constant it cannot change with time.  This is a limitation of the POSIX and C standards on which time module is based.

> For example, my mail sending program uses `email.utils.formatdate(localtime=True)', and that is returning a time one hour in the past currently.

I thought email.utils.formatdate was fixed in 3.x series.  Can you report this as a separate issue?

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