Proposal: API for thread-safe time zone functions

Jonathan Lennox lennox at cs.columbia.edu
Thu Jun 7 18:34:36 UTC 2001


On Thursday, June 7 2001, "John Cowan" wrote to "Jonathan Lennox, tz at elsie.nci.nih.gov" saying:

> > * Do people think that my proposal is a sensible API?
> 
> My main problem with it is that I see no point in the
> struct tz objects.  Programs don't typically do zillions
> of time conversions.  I would rather pass the time zone
> name to each externally vizible *_z function and let
> them look up the name in the currently maintained cache,
> if any.  We certainly want to discourage callers from
> trying to save the tz structure in a persistent database,
> since its content may change over time.

The problem with having a cache is that it exposes the tzcode to all the
inherent difficulties of thread-consistency and synchronization.  And I
think everyone would agree that *not* caching loaded tz information in some
way (either in the library or the client code) would be a bad idea.

It wouldn't be possible to save the tz structure in a *persistent* database,
if by that you mean non-volatile, because it contains private information.
Keeping it over the course of the lifetime of a process is perhaps more
troubling? 

Currently, tzcode doesn't notice (I believe) when /etc/localtime or the
zoneinfo files are modified out from underneath a running process.  You
could argue that this is less of a problem for the single-timezone
conceptual model, though.

> I also question the utility of a per-thread current time
> zone being maintained by the library, which then has to
> know what kind of thread library you have so it can discover
> the current thread ID.  Making something thread-safe at
> the cost of adding one argument to each tzlib call
> is not so bad.

The motivation for this section is to allow existing code which uses the
time functions to work with thread-safe timezones.  This model allows you,
e.g., to set a thread timezone and then call a function in an external
library to which you don't have source.

-- 
Jonathan Lennox
lennox at cs.columbia.edu
 



More information about the tz mailing list