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
