Steve Allen wrote: > But it is probably safer to come up >with a name for "the timescale my system clock keeps that I wish were >TAI but I know it really is not".
True. I can record timestamps in TAI(bowl.fysh.org), and by logging all its NTP activity I could retrospectively do a more precise TAI(bowl.fysh.org)<->TAI conversion than was possible in real time. To be rigorous we need to reify an awful lot more timescales than we do currently. Another aspect of rigour that I'd like to see is uncertainty bounds on timestamps. With NTP, as things stand now, the system clock does carry an error bound, which can be extracted using ntp_adjtime(). (Btw, another nastiness of the ntp_*() interface is that ntp_adjtime() doesn't return the current clock reading on all systems. On affected OSes it is impossible to atomically acquire a clock reading together with error bounds.) If I want a one-off TAI reading in real time, I can take the TAI(bowl.fysh.org) reading along with the error bound, and then instead of claiming an exact TAI instant I merely claim that the true TAI time is within the identified range. In that sense it *is* possible to get true TAI in real time, just not with the highest precision. If I have a series of timestamps from the same machine then for comparing them I don't want individual error bounds on them. The ranges would overlap and I'd be unable to sort them properly. This is another reason to reify TAI(bowl.fysh.org): the errors in the TAI readings are highly correlated, and to know that I can sort the timestamps naively I need to know that correlation, namely that they came from the same clock. Even in retrospect, when I can do more precise coversions to true TAI, I need to maintain the correlation, because the intervals between timestamps may still be smaller than the uncertainty with which I convert to TAI. >(or at least it is if you are one of Tom Van Baak's kids. See >http://www.leapsecond.com/great2005/ ) Cool. I'd have loved such toys when I was that age. My equivalent was that I got to experiment with a HeNe laser, as my father is a physicist. Now I carry a diode laser in my pocket. When TVB's children grow up, they'll probably carry atomic watches. >There seems little point in claiming to use a uniform time scale for a >reference frame whose rate of proper time is notably variable from >your own. Hmm. Seems to me there's use in it if you do a lot of work relating to that reference frame or if you exchange timestamps with other parties who use that reference frame. Just need to keep it in its conceptual place: don't assume that it's a suitable timescale for measuring local interval time. Another reason to reify a local timescale. > what happens when the operations of distributed systems demand >an even tighter level of sync than NTP can provide? Putting on my futurist hat, I predict the migration of time synchronisation into the network hardware. Routers at each end of a fibre-optic cable could do pretty damn tight synchronisation at the data-link layer, aided by the strong knowledge that the link is the same length in both directions. Do this hop by hop to achieve networked Einstein synchronisation. (And here come another few thousand timescales for us to process.) >What if general purpose systems do not have a means of acknowledging >and dealing with the fact that their system chronometer has deviated >from the agreeable external time, This has long been the case. Pre-NTP Unix APIs have no way to admit that the clock reading is bogus, and systems like Windows still have no concept of clock accuracy. What happens is that we get duff timestamps, and some applications go wrong. The number of visible faults that result from this is surprisingly small, so far. -zefram