RE: timestamp resolution

[Donn Terry]

I've been holding back on this one, but can't any longer.
Back around the time of the Y2K hoorah, we tried to solve this same set
of problems, and failed. The archive of that discussion is on the
website. And there's a good reason for that failure, and this discussion
is going down that same trap to the same failure.  (That failure, by the
way, was almost predictable from the prior attempts during the original
POSIX work in the 90s to deal with the problem.)

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

At the time I recommended that any future discussion in this area be
explicitly limited to system timestamps (for "nearby" times).  I suggest
that that limitation be imposed on this discussion, and that a separate
discussion be opened for astronomical times, which would be represented
as a separate type.

Another alternative is to wait until the languages and hardware have
evolved enough to make a larger-than-64-bit integer viable as a
timestamp.  (That is, as a native type.)  (96 or 128 bits doesn't
matter.)  (Or... what might make more sense: have POSIX require support
for such a type on conforming implementations.)  (Yeah, I know the
politics around that one.)  (Whether 96 or 128 bits is enough for
astronomical time I haven't tried to figure out.)

There's still a while before 2038 (when the current 32 bit timestamps
roll over), but the more time we have to get all systems onto something
that won't fall apart then, the less "Y2K-redux" we'll have.

Donn

-----Original Message-----
From: Hans Aberg [mailto:address@hidden 
Sent: Wednesday, May 09, 2007 4:51 AM
To: address@hidden
Cc: address@hidden
Subject: Re: timestamp resolution

I made a post to the moderated Usenet newsgroup sci.astro.research,  
"Julian day numbers and leap seconds", and there are so many  
responses, I cannot summarize them here.

The question of finding a good time suitable for distributed  
computing as well as in astronomy and sciences, plus syncing it with  
legal time is very complicated, and probably requires a committee of  
scientists and experts from a number of fields.

But one suggestion might using say TAI (International Atomic Time,  
with letters in French grammatical order), or possibly GPS time. It  
might be synced with say JD counted in seconds so that the difference  
becomes 0 today. Then leap seconds can be then be viewed as a feature  
of the UTC legal time.

TAI is the mean of highly accurate Cesium atomic clocks (the SI  
second is defined in terms of Cesium transitions), accuracy better  
than 10^-7, and is broadcast, so it can be used in computers via  
radio-controlled clocks (which are now commonly sold). see <http:// 
en.wikipedia.org/wiki/International_Atomic_Time>.

As for POSIX, I know that in some quarters, for example NASA when  
there is a satellite launch, one is very concerned over the problem  
not knowing which time the computers are set to. So it might be good  
to fix this gap in the POSIX standard.

   Hans Aberg