Akira Li added the comment: 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 ---------- nosy: +akira _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22752> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com