time.h design issues

Paul Eggert eggert at twinsun.com
Sun Aug 29 11:04:31 UTC 1999


   From: "D. J. Bernstein" <djb at cr.yp.to>
   Date: 28 Aug 1999 09:00:27 -0000

   Paul Eggert writes:
   > Kuhn and I are trying to specify an improved API for time handling.

   That doesn't answer the question. What problems are you trying to solve?
   How exactly is each of your API features used in real programs?

Justifying each feature of the API in detail would take some time.
Admittedly the rationale should be improved to do this.

The big picture: my main motivation is better support for time zones,
for programs like xtide (or the application that started this thread).
Kuhn is also motivated by the need for more precise characterization
of clocks.

   > Unfortunately, gettimeofday doesn't measure real time, at least not on
   > my Solaris box.  It measures the system's notion of the current time,
   > and this can jump when root adjusts the clock.

   ... If root sets the clock backwards, ``make'' can produce disastrously
   incorrect results. This is one of the reasons that your Solaris box has
   an adjtime() syscall that makes a gradual adjustment without screwing up
   monotonicity.

True, but (1) in practice many people set the clock directly, without
using adjtime, and (2) even adjtime can mess up benchmarks, the
application domain that you proposed gettimeofday for.  With
gettimeofday, one must make sure that nobody adjusts the system's
notion of the time of day while you're doing benchmarks.  With
TIME_MONOTONIC, you needn't worry about adjustments to the system
clock.

I agree that my proposed API is still too complicated.  When I get the
time I'll try to simplify it.  Your code is a valuable resource in
this area: implementation experience counts for a lot in my book.



More information about the tz mailing list