Extension to tzcode to support additional timezones
jhb at freebsd.org
Tue Oct 26 18:00:24 UTC 2010
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.
> > - 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:
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
> > 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. :-)
> > 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.)
More information about the tz