Extension to tzcode to support additional timezones

Guy Harris guy at alum.mit.edu
Tue Oct 26 16:58:20 UTC 2010


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?

> 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 mailing list