homepage

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.