"D. J. Bernstein" wrote on 1998-05-29 01:48 UTC:
On most systems, using TAI is quite problematic, because most time services publish exclusively UTC and not TAI (GPS being the notable exception). This means, a TAI clock is doomed to go wrong without periodic manual intervention (leaps seconds can be missed during downtimes). Therefore, I favour UTC as a timescale in computer applications. There are two possible ways of representing leap seconds in a UTC second count: (a) if you have a POSIX.1b style 32-bit nanosecond register that indicates the nanoseconds that have passed since the start of the last second, then just keep the second counter at 23:59:59 during the leap second and run with the nanosecond counter from 1_000_000_000 up to 1_999_999_999. or (b) define your integer time scale such that every day has 24*3600+1 seconds, i.e. you reserve a code for a potential leap second at the end of every day (or month). I prefer (a). It keeps us within the normally used UTC timebase and doesn't make things unnecessarily complicated on non-leapsecond aware systems. If you check out comp.std.unix, you'll see my posting about introducing in POSIX a CLOCK_UTC clock that is only present if the kernel has had a recent time service update and that doubles the nanosecond range during leap seconds. TAI and a correct difftime is practically never needed on normal computer applications. A correct difftime implementation on POSIX systems where the time_t scale explicitely does not provide codes for leap seconds is a joke of inconsistency. Leap seconds are a concern in distributed systems, where strictly monotonic precision timestamps are necessary (e.g., banking databases), but here the two gigananoseconds (2 Gns) approach (a) works nicely. TAI is only of concern in very special purpose systems such as navigation and astronomical/geological observations. It's nice to have TAI available, but it should not be used as the primary timescale. It is just an auxiliary timescale that happens to be accessable on systems with a builtin GPS receiver or with some future TAI enhanced NTP version. My preferred timestamp format would be the UTC96/2000 format, i.e. a signed Bigendian 64-bit second counter starting with 0 at 2000-01-01 00:00:00Z followed by a 32-bit Bigendian nanosecond counter. Alternative nice epoch start dates could be the year 0 (also known as 1 B.C.) of the Gregorian (!) calendar, or the year 1875 (when the Metric Convention was signed in Paris and the Gregorian Calendar was already widely implemented). 0 simplifies implementation of conversion routines slightly but might cause historic confusion. Attosecond timescales are practically useless for the forseeable future. The best Cesium clocks in the world (currently the CS1 and CS2 operated by PTB in Braunschweig) do not reach 1 ns precision, nor does USNO's clock-array regulated hydrogen maser in Washington DC. Electric impulses in wires travel only around 20 cm per nanosecond, and relativistic effects really start to make things confusing you if you want to build clocks with more than 1 ns precision. So your TIA64NA sounds to me much like an overkill specification. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>