Jonathan Lennox wrote:
* Are people interested in this?
I think it's a good idea.
* 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. This would require adding a new function to retrieve the tz_name array for a given time zone name. 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. -- There is / one art || John Cowan <jcowan@reutershealth.com> no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein