[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 15:09:55 +0200

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

reply via email to

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