On Thursday, June 7 2001, "John Cowan" wrote to "Jonathan Lennox, tz@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@cs.columbia.edu