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.
<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
More information about the tz
mailing list