Re: timestamp resolution

[Hans Aberg]

On 9 May 2007, at 16:30, Joseph M Gwinn wrote:

> In fact, POSIX "Seconds Since the Epoch" is effectively TAI minus an
> unspecified offset because POSIX counts ~SI seconds regardless of
> astronomy and thus leap anything.

I think the specs ignore the issue, so it is only accurate within a  
couple of ten seconds. I figure typical system just ignore the leap  
seconds from the epoch, and adjusts the internal clock on the first  
lookup after the time server has changed. It is these jumps in the  
internal clock that may pose a problem: it is hard to tell which  
computer that have adjusted and which have not.

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.

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


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

> As for the choice of the one true clock, the original and still a core
> reason for POSIX to care about time is to support causal ordering  
> of file
> updates by comparison of timestamps.
>
> The granularity issue has always been with us.  While it is known  
> that no
> finite-resolution timestamp scheme can ensure causal order, the
> alternative (a central guaranteed-sequence hardware utility) is  
> usually
> impractical, so people have always used timestamps.  (IBM sells such a
> utility box for use in their transaction systems.)  What one can most
> easily do is to require much better timestamp resolution as technology
> progresses, thus reducing the window of non-causality in such  
> things as
> make.

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.

  Hans Aberg