FW: Extension to tzcode to support additional timezones

Olson, Arthur David (NIH/NCI) [E] olsona at dc37a.nci.nih.gov
Tue Oct 26 16:03:14 UTC 2010


I'm forwarding this message from John Baldwin, who is not on the time zone mailing list.
Those of you who are on the list, please direct replies appropriately.

        --ado
________________________________________
From: John Baldwin [jhb at freebsd.org]
Sent: Tuesday, October 26, 2010 11:20 AM
To: tz at lecserver.nci.nih.gov
Subject: Extension to tzcode to support additional timezones

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