Extension to tzcode to support additional timezones

lennox at cs.columbia.edu lennox at cs.columbia.edu
Tue Oct 26 20:15:30 UTC 2010

On Tuesday, October 26 2010, "Christos Zoulas" wrote to "tz at lecserver.nci.nih.gov, tz at 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.


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 at cs.columbia.edu

More information about the tz mailing list