On Tuesday, October 26 2010, "Christos Zoulas" wrote to "tz@lecserver.nci.nih.gov, tz@lecserver.nci.nih.gov" saying:
BTW, tm->tm_zone is broken right now since it just does:
tmp->TM_ZONE = &sp->chars[ttisp->tt_abbrind];
and if I call tzset() with a different zone and try to lookup tmp->TM_ZONE this will possibly point to junk.
This is why the POSIX specification of strftime says: If a struct tm broken-down time structure is created by localtime() or localtime_r(), or modified by mktime(), and the value of TZ is subsequently modified, the results of the %Z and %z strftime() conversion specifiers are undefined, when strftime() is called with such a broken-down time structure. <http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html> This was directly inspired by the fact that the strftime "%Z" conversion specifier just prints the contents of tm_zone, on platforms that have it, and in the described scenario that field does indeed point to junk. Could one apply the same constraint to using the tm_zone field or the %Z conversion specifier following a call to tz_free() (or whatever one wants to call it)? -- Jonathan Lennox lennox@cs.columbia.edu