Extension to tzcode to support additional timezones

John Baldwin 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.
> 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:

	localtime_r(&t, &tm);

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

More information about the tz mailing list