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:[EMAIL PROTECTED] Sent: Wednesday, May 09, 2007 4:51 AM To: [EMAIL PROTECTED] Cc: bug-make@gnu.org 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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
