time.h design issues

[D. J. Bernstein]

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?

> I hadn't intended for the improved time API to address calendrical
> issues, but if there's a demand for this it could be added.

Civil-time conversions make essential use of basic calendar functions.
It's silly to hide these functions.

> 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.

Time for a reality check.

The OS stores a single ``last modification'' timestamp for each file.
These timestamps are compared by the ``make'' file-construction tool.

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.

> However, we must have the ability to handle
> multiple time zones simultaneously

I agree that the basic convert-to-civil-time function should allow a
zone argument.

---Dan