Re: timestamp resolution

[Hans Aberg]

On 9 May 2007, at 16:45, Donn Terry wrote:

> It is simply NOT possible to satisfy both the
> timestamp-for-system-events needs of the real time people (who really
> want attosecond resolution -- maybe only 10s or 100s, but really tiny)
> and the huge range needed for astronomical needs.  The system  
> timestamps
> need to be "fast and lightweight", which means an integer or at  
> worst a
> struct of integers.  That doesn't work for astronomical time, which
> really should be floating point.

Aren't you confusing a method of coordinating different time scales  
with the idea of finding a time scale, suitable for all purposes?

I dealt with the former issue, in view of that even within astronomy,  
it is not possible to find a single time scale, suitable for all  
purposes. For example, GPS time must introduce GR corrections, and  
there are several different types of atomic time, depending on  
whether they are on planet Earth, or somewhere else n the Solar system.

> Floating point doesn't work right for timestamps (e.g. make) if the
> mantissa is too small and times that should be distinct, aren't.  
> I'm not
> going to try to repeat the calculations I did back when, but to  
> cover a
> range that covers the "nearby" times (say, +- 2000 years) at the
> resolution the realtime people need takes more than 64 bits.  (66  
> or 67
> if I remember correctly -- 64 is an achievable compromise, but it is a
> compromise on one end or the other.)

So this isn't relevant. One can use several different time scales,  
for different purposes, but coordinating them against a TAI-JD.

Otherwise, the age of the Universe, according to current theories, is  
about 15 billion years, or about 4.7e17 seconds, can fits within 58  
bits, and I doubt, one has need for pinning it down more  
accurately. :-) And the atomic clocks are only accurate within 10^-7,  
so nanoseconds expressed as 32-bits would suffice today.

But that would just be one time scale:

If current UNIX time is adjusted, it would, as is now, ignore past  
and future leap seconds in the internal counting of seconds, but if  
future leap seconds or leap whatever do occur, when converted to  
human time stamps, there would need to be an adjustment.

  Hans Aberg