Extension to tzcode to support additional timezones

[Christos Zoulas]

On Oct 26,  4:15pm, lennox at cs.columbia.edu (lennox at cs.columbia.edu) wrote:
-- Subject: Re: Extension to tzcode to support additional timezones

| > 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)?

Yes, we can document the failure scenarios (it is fairly complex to do it
correctly, but doable; for example there are no such warnings for tm_zone
that I know of [1]), or we can try to fix them if people think it is worth-
while and the implementation is not overly complicated.

christos

[1] the man page (NetBSD) just says:
    The tm_zone and tm_gmtoff fields exist, and are filled in, only if
    arrangements to do so were made when the library containing these func-
    tions was created.  There is no guarantee that these fields will continue
    to exist in this form in future releases of this code.

-- I don't even understand what that means :-)