On Thursday, June 7 2001, "Markus Kuhn" wrote to "tz@elsie.nci.nih.gov" 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 timezones. 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@cs.columbia.edu