time.h design issues

Scott Harrington seh4 at ix.netcom.com
Sat Aug 28 02:55:35 UTC 1999


"D. J. Bernstein" wrote:
> 
> Paul Eggert writes:
> > http://www.twinsun.com/tz/timeapi.html
> 
> 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?



More information about the tz mailing list