Alexander Belopolsky added the comment: I ran the attached test-mktime.c program on Linux and MacOS X with the following results (TZ=America/New_York):
$ cat test-mktime.c #include <time.h> #include <stdio.h> static void print_globals(struct tm *tm) { printf("%04d-%02d: %s/%s (%s) %d %ld (%ld)\n", 1900 + tm->tm_year, 1 + tm->tm_mon, tzname[0], tzname[1], tm->tm_zone?tm->tm_zone:"NULL", daylight, timezone, -tm->tm_gmtoff); } int main() { struct tm tm = {0, 0, 0, 1, 0, -100}; print_globals(&tm); tzset(); print_globals(&tm); mktime(&tm); print_globals(&tm); tm.tm_year = 43; mktime(&tm); print_globals(&tm); tm.tm_year = 45; tm.tm_mon = 8; mktime(&tm); print_globals(&tm); } Linux: $ gcc test-mktime.c && ./a.out 1800-01: GMT/GMT (NULL) 0 0 (0) 1800-01: EST/EDT (NULL) 1 18000 (0) 1800-01: LMT/EDT (LMT) 1 18000 (17762) 1943-01: EST/EWT (EWT) 1 18000 (14400) 1945-09: EST/EPT (EPT) 1 18000 (14400) MacOS X: $ clang test-mktime.c && ./a.out 1800-01: WILDABBR/WILDABBR (NULL) 0 0 (0) 1800-01: EST/EDT (NULL) 1 18000 (0) 1800-01: EST/EDT (NULL) 1 18000 (0) 1943-01: EST/EWT (EWT) 1 18000 (14400) 1945-09: EST/EPT (EPT) 1 18000 (14400) Indeed, mktime changes tzname as a side effect, but the result is system dependent (see LMT/EDT vs. EST/EDT in the third line). Furthermore, the values of daylight and timezone variables do not get updated, resulting in an inconsistent state. For this reason, I don't think Python should expose the new values of tzname. People who really need access to those can use ctypes. ---------- resolution: -> wont fix stage: patch review -> resolved status: open -> closed Added file: http://bugs.python.org/file44641/test-mktime.c _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22798> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com