On Tuesday, October 26, 2010 12:58:20 pm Guy Harris wrote:
On Oct 26, 2010, at 9:03 AM, Olson, Arthur David (NIH/NCI) [E] wrote:
Several of my employers have needed to work with data from multiple timezones within a single process. The traditional way to work with this has been to change the value of the TZ environment variable and invoke tzset() and switch between timezones one at a time. What I have done is extend the time(3) API to allow applications to load and use arbitrary timezones separate from the current local and GM timezones. I've done this by adding the following API calls:
- void *tzopen(const char *name). This loads the rules for a specified timezone and returns a void * cookie. If the zone cannot be parsed it returns NULL and sets errno to EINVAL.
- void tzclose(void *zone). This "closes" a set of rules opened via tzopen() by releasing the associated resources.
Note that, on several OSes - including, as I remember, FreeBSD - "struct tm" includes a "tm_zone" field, which points to the timezone abbreviation for the time in question.
If:
- struct tm *tztime(void *zone, const time_t *t, struct tm *tm). This is like localtime_r() except that it uses the timezone rules from the passed in cookie instead of the local timezone indicated by TZ.
a program calls tzopen(), tztime(), and then tzclose(), is the "tm_zone" field in the "struct tm" filled in by tztime() still valid?
No. However, I think this case is similarly broken: putenv("TZ=America/New_York"); tzset(); time(&t); localtime_r(&t, &tm); putenv("TZ=Europe/London"); tzset(); at this point I believe that tm_zone will not point to "EST" and "EDT", but probably the London equivalents (FreeBSD's localtime.c uses the case where there is static storage backing lclptr and gmtptr). In the ALL_STATES case I think tm_zone would reference free'd memory just as in the case you point out above.
I have a patch that is relative to the FreeBSD source tree, but all of the real code changes are in localtime.c which I believe should apply directly to the tzcode distribution. The patch is available at http://www.FreeBSD.org/~jhb/patches/tzopen.patch
"404 - Not Found" isn't much of a patch. :-)
Oops, fixed.
Is this API something that you folks would be interested in? I currently have this as a private patch locally, but if possible I would like it adopted upstream.
People have been suggesting this sort of thing on several occasions, so we'd be interested in an API of this sort. (In the past, I'd proposed support for this, with a patch, and somebody pointed out the tm_zone issue.)
-- John Baldwin