Extension to tzcode to support additional timezones

[lennox at cs.columbia.edu]

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.

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