Proposal: API for thread-safe time zone functions

Jonathan Lennox lennox at
Thu Jun 7 19:27:33 UTC 2001

On Thursday, June 7 2001, "Markus Kuhn" wrote to "tz at" saying:

> Garrett Wollman wrote on 2001-06-07 17:11 UTC:
> > All of these suggestions are essentially orthogonal to the main issue
> > of re-entrant, thread-specific time conversions.  I suggest that
> > Mr. Lennox's proposal is much more likely to be gain concensus than
> > any changes to the underlying interfaces.
> IMHO, API's should be designed properly right from the beginning,
> because they can't be withdrawn in the future. The world is already full
> of quick-add-on reentrant API fixes that later had to be again
> superseded by something different, because only the thread-safely and
> none of the other accumulated problems had been addressed.

I think there's need for APIs to interact with both time_t's and your
xtime_t's (or whatever they end up being called) using thread-safe

Since I believe you didn't modify struct tm in your proposal, only the
conversion functions (the equivalents of mktime and localtime) need to be
different for the two datatypes.  Your naming choices: xtime_make() and
xtime_breakup() -- imply obvious names for time_t-based equivalents
(time_make() and time_breakup() respectively).

Jonathan Lennox
lennox at

More information about the tz mailing list