Extension to tzcode to support additional timezones
Christos Zoulas
christos at zoulas.com
Tue Oct 26 20:31:42 UTC 2010
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 :-)
More information about the tz
mailing list