Extension to tzcode to support additional timezones

John Baldwin jhb at freebsd.org
Tue Oct 26 15:20:22 UTC 2010


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.

- 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.

- time_t timetz(void *zone, struct tm * const tm).  This is like mktime() 
except that it uses the timezone rules from the passed in cookie instead of 
the local timezone indicated by TZ.

The changes to the code are fairly simple since the per-zone state was already 
broken out into a standalone state object to handle GMT vs local time.  In 
some cases the patches make things cleaner (I think) by removing hacks where a 
function pointer was queried to determine which state object to use since the 
state object pointer is now passed all the way down the internal time code 
stack.

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

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.

-- 
John Baldwin



More information about the tz mailing list