Issue 22752: incorrect time.timezone value (original) (raw)

Issue22752

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 (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)
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" -14400
msg230160 - (view)	Author: Alexander Belopolsky (belopolsky) *	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. https://docs.python.org/3/library/datetime.html#datetime.datetime.astimezone
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) *	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 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 - 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