This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: incorrect time.timezone value
Type: behavior Stage: resolved
Components: Versions:
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: akira, barry, belopolsky, errx, mitya57, r.david.murray
Priority: normal Keywords:

Created on 2014-10-28 14:26 by errx, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (6)
msg230153 - (view) Author: matrokhin oleg (errx) Date: 2014-10-28 14:26
There was timezone change in Russia at 26 october (

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)
msg230154 - (view) Author: matrokhin oleg (errx) Date: 2014-10-28 14:28
$ date -R    
Tue, 28 Oct 2014 17:27:54 +0300

$ python -c "import time; print time.timezone"
msg230160 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-10-28 16:42
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.
msg231603 - (view) Author: Dmitry Shachnev (mitya57) * Date: 2014-11-24 15:02
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.
msg231606 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-11-24 16:08
> 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?
msg231640 - (view) Author: Akira Li (akira) * Date: 2014-11-25 06:22
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

C tzname, timezone, daylight are not constants. They may change e.g., see (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 

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


Date User Action Args
2022-04-11 14:58:09adminsetgithub: 66941
2015-03-01 19:56:57belopolskysetstatus: open -> closed
2014-11-25 06:22:19akirasetnosy: + akira
messages: + msg231640
2014-11-24 16:08:14belopolskysetnosy: + barry, r.david.murray
messages: + msg231606
2014-11-24 15:02:46mitya57setstatus: pending -> open
nosy: + mitya57
messages: + msg231603

2014-11-24 14:41:11r.david.murraylinkissue22930 superseder
2014-10-28 16:42:16belopolskysetstatus: open -> pending
messages: + msg230160

assignee: belopolsky
resolution: not a bug
stage: resolved
2014-10-28 14:36:12ezio.melottisetnosy: + belopolsky
2014-10-28 14:28:32errxsetmessages: + msg230154
2014-10-28 14:26:38errxcreate