I have a multithreaded server that has a thread per client, and needs to talk to clients in their local timezone. All the "normal" UNIX time functions rely on "TZ" for timezone information, so even though they're nominally "thread-safe" they don't support my application, since TZ is global across threads. Is there a localtime()-like implementation out there that can do what I need, or do I have to write one? And if not and I have to write one, what code base is the "correct" one to start from (e.g. Linux, tzcode2003e.tar.gz from elsi.nci.nih.gov, etc.)? Thanks, -- Michael Lindner
On Tue, Aug 03, 2004 at 03:04:39PM -0400, Michael Lindner <mlindner@idttechnology.com> wrote:
I have a multithreaded server that has a thread per client, and needs to talk to clients in their local timezone. All the "normal" UNIX time functions rely on "TZ" for timezone information, so even though they're nominally "thread-safe" they don't support my application, since TZ is global across threads.
Is there a localtime()-like implementation out there that can do what I
I am sure others will additionally have useful advise, but why don't you just put a lock around your calls to localtime? localtime is rarely a bottleneck (it might be for your application), so this shouldn't be a problem. -- The choice of a | -----==- _GNU_ | ----==-- _ generation Marc Lehmann +-- ---==---(_)__ __ ____ __ pcg@goof.com |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE | |
On Tuesday, August 3 2004, "Michael Lindner" wrote to "Tz" saying:
I have a multithreaded server that has a thread per client, and needs to talk to clients in their local timezone. All the "normal" UNIX time functions rely on "TZ" for timezone information, so even though they're nominally "thread-safe" they don't support my application, since TZ is global across threads.
Is there a localtime()-like implementation out there that can do what I need, or do I have to write one? And if not and I have to write one, what code base is the "correct" one to start from (e.g. Linux, tzcode2003e.tar.gz from elsi.nci.nih.gov, etc.)?
I implemented one a while back, based on the then-current version of tzcode with some input from its FreeBSD variant. I've attached my message implementing it below. It's based on tzcode2001c. It might be a bit of work to update it to the current version of tzcode; I've not tried it. Licensed under the standard tzcode license, i.e. public domain. For discussion of it, check out the archives of the tz list from June 2001.
Michael Lindner <mlindner@idttechnology.com> writes:
Is there a localtime()-like implementation out there that can do what I need, or do I have to write one?
I think the latter, unless you want to use Java <http://www.bmsi.com/java/#TZ>. Jonathan Lennox proposed a C API in http://www.cl.cam.ac.uk/~mgk25/time/c/proposal-lennox.txt I vaguely recall that something got implemented; perhaps you can consult the archive of the tz mailing list.
And if not and I have to write one, what code base is the "correct" one to start from (e.g. Linux, tzcode2003e.tar.gz from elsi.nci.nih.gov, etc.)?
GNU/Linux (i.e., glibc) and tzcode are both reasonable. Neither is bug-free. GNU/Linux currently has some problems with negative time stamps; tzcode with large 64-bit time_t values -- choose your poison. GNU/Linux is LPGLed and is probably more widely used; tzcode is public domain.
Paul Eggert wrote:
GNU/Linux (i.e., glibc) and tzcode are both reasonable.
Thanks for the info. The tzcode code is a lot cleaner and easier to modify the way I want. All other things being equal (or at least similar) that's the way to go. Jonathan Lennox wrote:
I've attached my message implementing it below. It's based on tzcode2001c. It might be a bit of work to update it to the current version of tzcode;
Thanks! This looks like exactly what I need. Your mods (adding an "opaque" struct to represent a parsed tz entry) is what I would have done. pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:
localtime is rarely a bottleneck (it might be for your application), so this shouldn't be a problem.
Thanks for the suggestion, but unfortunately, it is a bottleneck in this application. -- Michael Lindner
participants (4)
-
Jonathan Lennox -
Michael Lindner -
Paul Eggert -
pcg＠goof.com