Proposal for new ISO C 9x time API

[Ken Pizzini]

In message <199809182051.NAA01889 at shell7.ba.best.com>,
Nathan Myers <ncm at best.com> writes:
> Can we discuss the rest of the proposal?
> The URL was:  http://www.cl.cam.ac.uk/~mgk25/c-time/

Well, part of the reason for my focusing on the trivial issue
of what to name the basic data type is that I'm pretty happy
with the real substance.

One other fragment that mildly bothers me is in the Implementation
Advice to {xtime,chron{,os}}_conv(), where Markus has:
:    Implementations can also offer the application to
:   convert TIME_MONOTONIC values into TIME_TAI or TIME_UTC values as soon
:   as these clocks have been adjusted using an external reference. This
:   way, TIME_MONOTONIC values that were measured at a time when the   
:   implementation had not yet been able to determine UTC or TAI can later
:   be converted as soon as contact with the reference clock is
:   established.

I feel that it would be helpful to further advise implementors on
what they might do (or at least that it is an issue that they ought
to consider) if, after synchronization with TIME_UTC or TIME_TAI
becomes established, it is discovered that the TIME_MONOTONIC clock has
been running with its "second" of a substantially different duration
than a TAI second?  (Say, 0.1 TAI second/pre-sync monotone second,
or 10 TAI seconds/pre-sync monotone second, perhaps due to a change
in underlying hardware that the software is running on, and without a
suitable pre-syncronization time base to calibrate to.  Even a (perhaps
more realistic) 1.01 TAI second/monotone second could be considered
"substantial" by some.)

Perhaps add a sentence along the lines of:
   When making such a conversion, a high-quality implementation
   would take into account any difference in clock-rates that may
   have been discovered.
?

		--Ken Pizzini