From: "D. J. Bernstein" <djb@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.