"D. J. Bernstein" wrote:
Paul Eggert writes:
I don't understand what problems you're trying to solve here.
Time libraries should be designed to support the features that real programs need. [....]
Robert E. Brown's query very concisely pointed out two fundamental problems with existing time libraries: thread safety, and performing conversions to and from multiple "local" time zones in a single program. Simulation and real-time programs, for instance in the financial arena, need to know about past, present, and future offsets and DST rules for locales all around the world. Nothing infuriates me more than seeing "US rules" hardcoded in some supposed timezone helper class; this is the whole reason the tz list exists. I'll grant you that there are not a lot of us who demand conversions to and from lots of "local" time zones, over spans of many years, in a single (possibly multi-threaded) performance-sensitive application. But these are "real programs". The calendar arithmetic issues Paul Hill brought up are another story altogether. Whether these should be part of a standard C library is debatable. I for one would favor a portable standalone implementation of xtime, timezone_t, etc. a la Kuhn & Eggert. Seems like that would be easier to maintain and port. Why expect so much of the OS vendor?