[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: timestamp resolution

From: Hans Aberg
Subject: Re: timestamp resolution
Date: Thu, 10 May 2007 21:53:09 +0200

On 10 May 2007, at 20:42, Joseph M Gwinn wrote:

The POSIX.1 standard is very specific, and each and every word was
hard-fought.  I would parse it (and the corresponding Rationale) very
slowly and carefully.  Even the things not said are important.

There is no intent to put astronomical or attosecond time in the POSIX
core. The intent is to support file timestamps and realtime timers and
timeouts and the like.

Right. Todays computers are wholly unsuitable for measuring time or displaying it beyond the typical desktop clock.

Nor do astronomers need their various clocks built into the operating
system, as for the astronomers time is just another kind of data, as they
compute events remote from the here and now.  Likewise physicists.

Well, to me it looked as though astronomers and others interested in time measurements would want better capacity than that. To those that are not computer experts, it is a bit confusing that computer time is unrelated to physical time, despite using language like the epoch is January 1, 1970.

If one keeps building computers with rather poor time keeping, then there is no need to sync system time to anything in the real physical world. But if they improve, say by increased use of GPS devices or whatever, then this might change.

If one would follow the suggestion of using a TAI-JD the way I did,
one would end up with a system that ignores the leap system in the
internal second count, from the epoch. It means that one must have
time servers that do not introduce a jump when a leap second appears.
Instead, when a human readable time stamp occurs, one makes a lookup
from a file, that adjusts the time accordingly.

One can already use NTP to slave ones computer to GPS System Time to
achieve this.  All the big radars I work on do just that.  Set the GPS
receiver to emit "GPS time" (not "UTC"), and point NTP in the workstations
and servers to the NTP server attached to that GPS receiver.

So then syncing UNIX time against that would not require any change at all. If one wants to display UTC, and if there is a leap second introduced, one would need to change the software for that interface. (Though I do not know the relation between GPS time, probably owned by the US military, and TAI, which aims at approximating TT.)

(The fact that ordinary computer clock
hardware isn't nearly as accurate as that collection of caesium beam
clocks is neither here nor there - it's the semantics of the
timescale, not its accuracy, that counts here.)

Right. The idea is not to impose a system on the current hardware,
but admitting future hardware with more accurate clocks to adjust at
need. This need not only to be file time stamps, but say distributed
ronoting, or something.


Sorry, "roboting". If one has a setup of different robots, then one can do that directly via a program and communications. But one could use synced clocks and let them work without direct communication, or only at need. Of course, todays computers are wholly unsuitable for that. Just a line of thought.

POSIX time cannot actually be TAI bacause not all POSIX systems have
access to (or need for) time that's accurate with respect to any
external timescale.  Think isolated networks with no access to the

A completely isolated system only needs adjustment to its one and
only clock. In a distributed setting, be it over the network, or by
radio broadcasts, need access to time servers which do not introduce
a leap second in the count.

Don't assume that an isolated system can only be a single computer with a single clock. The big radars for instance consist of tens of computers,
many network components, and two GPS receivers (and associated NTP
timeservers), all in a ten story high building.

So then, when there is more than one clock, one has to think very carefully what one want to do with them. If it is physical causality, then GR sets a light-cone limitation, or about 0.3 m per nano-second.

So for the purpose of sorting out logical causality in a computer, it is probably not physical time stamps one is out for. Whatever it is, it should probably not be called "time stamps". :-)

Different system will require different granularity. The interesting
thing is that a high performance system distributed around planet
Earth might in principle have an accuracy of 10^-7 seconds.

One can actually do far better than that already, but it's expensive.
Again, astronomers were the pioneers. Look into VLBIs (Very Long Baseline Interferometers). Also the HP app note "TheScienceOfTimekeeping.pdf" has
a nice summary of the precision achievable by various methods.

So one cannot expect there to be one single precision time scale. Also, it is possible to use finer grains in time syncing than it is possible to sort out physical causality. So this time keeping is not then suitable to sort out the causality, as you want to do with the filesystem so called "time stamps".

  Hans Aberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]