Not if you are writing applications that need high performance processing of multiple timezones and access from multiple languages and platforms. Besides, we're multi-threaded. Changing environment variables is simply not an option. Yikes! Can you say race condition. From: bent@latency.net [mailto:bent@latency.net] On Behalf Of Bennett Todd Sent: Wednesday, November 02, 2011 9:09 AM To: Thom Hehl Subject: Re: [tz] Reading binary files The binary files are a distraction. What you want to do is set the environment variable TZ to the name of the zone you want, then call tzset which is what consults the database and prepares for conversion. Then localtime(3) will translate a time_t (seconds since the epoch) to hours, minutes, seconds, etc in the local timezone. For translating back and forth you repeatedly reset TZ, call tzset(3), and localtime(3). Those are the standards for Unix, the native home of the zoneinfo database. If you're on a different system details may vary. But on Unix the database is probably already installed in your system and the subroutines you need are already compiled into the system library.
As far as I know, the choices for a high-speed timezone-switching implementation, thread-safe, are going to a different implementation (I don't know what would be best) or stashing the zoneinfo conversion in a separate process as a server, a tz conversion service. On Nov 2, 2011 11:05 AM, "Thom Hehl" <Thom@pointsix.com> wrote:
Not if you are writing applications that need high performance processing of multiple timezones and access from multiple languages and platforms. Besides, we’re multi-threaded. Changing environment variables is simply not an option. Yikes! Can you say race condition.****
** **
*From:* bent@latency.net [mailto:bent@latency.net] *On Behalf Of *Bennett Todd *Sent:* Wednesday, November 02, 2011 9:09 AM *To:* Thom Hehl *Subject:* Re: [tz] Reading binary files****
** **
The binary files are a distraction.****
What you want to do is set the environment variable TZ to the name of the zone you want, then call tzset which is what consults the database and prepares for conversion. Then localtime(3) will translate a time_t (seconds since the epoch) to hours, minutes, seconds, etc in the local timezone.*** *
For translating back and forth you repeatedly reset TZ, call tzset(3), and localtime(3). Those are the standards for Unix, the native home of the zoneinfo database. If you're on a different system details may vary. But on Unix the database is probably already installed in your system and the subroutines you need are already compiled into the system library.****
On Wed, 02 Nov 2011, Bennett Todd wrote:
As far as I know, the choices for a high-speed timezone-switching implementation, thread-safe, are going to a different implementation (I don't know what would be best) or stashing the zoneinfo conversion in a separate process as a server, a tz conversion service.
Christos Zoulas posted a proposed API and patches in October 2010. For example, localtime_rz() is like localtime() but it takes extra args giving a pointer to a buffer that will hold the result, and a data structure describing the timezone. --apb (Alan Barrett)
I have done a version of C library that export the struct that contains zone definitions, and one can load many zones to these structs and call localtime etc. with the struct as a parameter. Sorry cannot share that code, not that there is any secret in it but cannot spare the time at the moment to clean it up and export. Just a hint that it is not a huge task to modify the current C library to be thread safe and efficient that way. Just a hint. Don't shoot me for not sharing the actual code. Jaakko On Wed, 2 Nov 2011, Bennett Todd wrote:
As far as I know, the choices for a high-speed timezone-switching implementation, thread-safe, are going to a different implementation (I don't know what would be best) or stashing the zoneinfo conversion in a separate process as a server, a tz conversion service. On Nov 2, 2011 11:05 AM, "Thom Hehl" <Thom@pointsix.com> wrote:
Not if you are writing applications that need high performance processing of multiple timezones and access from multiple languages and platforms. Besides, we’re multi-threaded. Changing environment variables is simply not an option. Yikes! Can you say race condition.****
** **
*From:* bent@latency.net [mailto:bent@latency.net] *On Behalf Of *Bennett Todd *Sent:* Wednesday, November 02, 2011 9:09 AM *To:* Thom Hehl *Subject:* Re: [tz] Reading binary files****
** **
The binary files are a distraction.****
What you want to do is set the environment variable TZ to the name of the zone you want, then call tzset which is what consults the database and prepares for conversion. Then localtime(3) will translate a time_t (seconds since the epoch) to hours, minutes, seconds, etc in the local timezone.*** *
For translating back and forth you repeatedly reset TZ, call tzset(3), and localtime(3). Those are the standards for Unix, the native home of the zoneinfo database. If you're on a different system details may vary. But on Unix the database is probably already installed in your system and the subroutines you need are already compiled into the system library.****
-- Foreca Ltd Jaakko.Hyvatti@foreca.com Tammasaarenkatu 5, FI-00180 Helsinki, Finland http://www.foreca.com
BANG!!!!!! Oops, sorry, shot before reading last sentence. -----Original Message----- From: Jaakko Hyvätti [mailto:jaakko.hyvatti@foreca.com] Sent: Wednesday, November 02, 2011 11:34 AM To: Bennett Todd Cc: Thom Hehl; tz@iana.org Subject: Re: [tz] Reading binary files I have done a version of C library that export the struct that contains zone definitions, and one can load many zones to these structs and call localtime etc. with the struct as a parameter. Sorry cannot share that code, not that there is any secret in it but cannot spare the time at the moment to clean it up and export. Just a hint that it is not a huge task to modify the current C library to be thread safe and efficient that way. Just a hint. Don't shoot me for not sharing the actual code. Jaakko On Wed, 2 Nov 2011, Bennett Todd wrote:
As far as I know, the choices for a high-speed timezone-switching implementation, thread-safe, are going to a different implementation (I don't know what would be best) or stashing the zoneinfo conversion in a separate process as a server, a tz conversion service. On Nov 2, 2011 11:05 AM, "Thom Hehl" <Thom@pointsix.com> wrote:
Not if you are writing applications that need high performance processing of multiple timezones and access from multiple languages and platforms. Besides, weʼre multi-threaded. Changing environment variables is simply not an option. Yikes! Can you say race condition.****
** **
*From:* bent@latency.net [mailto:bent@latency.net] *On Behalf Of *Bennett Todd *Sent:* Wednesday, November 02, 2011 9:09 AM *To:* Thom Hehl *Subject:* Re: [tz] Reading binary files****
** **
The binary files are a distraction.****
What you want to do is set the environment variable TZ to the name of the zone you want, then call tzset which is what consults the database and prepares for conversion. Then localtime(3) will translate a time_t (seconds since the epoch) to hours, minutes, seconds, etc in the local timezone.*** *
For translating back and forth you repeatedly reset TZ, call tzset(3), and localtime(3). Those are the standards for Unix, the native home of the zoneinfo database. If you're on a different system details may vary. But on Unix the database is probably already installed in your system and the subroutines you need are already compiled into the system library.****
-- Foreca Ltd Jaakko.Hyvatti@foreca.com Tammasaarenkatu 5, FI-00180 Helsinki, Finland http://www.foreca.com
<<On Wed, 2 Nov 2011 10:58:05 -0400, "Thom Hehl" <Thom@pointsix.com> said:
Not if you are writing applications that need high performance processing of multiple timezones and access from multiple languages and platforms. Besides, we're multi-threaded. Changing environment variables is simply not an option. Yikes! Can you say race condition.
A thread-safe API has been proposed on the predecessor to this list a few times in the recent past, and I believe someone actually posted patches at one point. This would give you versions of tzset(), localtime(), and mktime() that used explicit (non-shared) state rather than the shared state required by the functions in the C standard. -GAWollman
On Nov 2, 10:58am, Thom@pointsix.com ("Thom Hehl") wrote: -- Subject: Re: [tz] Reading binary files | Not if you are writing applications that need high performance | processing of multiple timezones and access from multiple languages and | platforms. Besides, we're multi-threaded. Changing environment variables | is simply not an option. Yikes! Can you say race condition. I submitted a patch to the list that makes all the functions thread-safe and multi-timezone friendly more than a year ago. I've committed the patch to the NetBSD tree together with documentation: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/time/?only_with_tag=MAIN I have also added glibc compatibility for mktime() in the DST gap. Enjoy, christos
participants (6)
-
Alan Barrett -
Bennett Todd -
christos＠zoulas.com -
Garrett Wollman -
Jaakko Hyvätti -
Thom Hehl