On Oct 26, 4:15pm, lennox@cs.columbia.edu (lennox@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 :-)