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.