Re: timestamp resolution

[Hans Aberg]

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

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