Peter Simons
You can map TAI to calendar time iff that date is in the past or in the near future. (I think leap seconds are announced at least a year before they occur or so.) That makes TAI unsuitable as an internal representation for most applications.
I think it's half a year. It was recently announced that there will be no leap second in the middle of 2005. Someone said that tsunami made the earth rotate a bit faster. The leap second system will have to be abandoned after a hundred of years or so, because the long-time trend is Earth slowing down, so there will be more and more leap seconds. There is a proposal of adding a hour at a time, not a second at a time. These events would be much more rare, so people could prepare to them in advance. Only astronomers would be upset, because the angle of Earth rotation at a given hour would drift as time passes. One reason of using UTC instead of TAI is that most computer languages and protocols use UTC or something derived from it.
IMHO, a good choice to store distance in time is:
type TimeDiff = (Integer, Float)
With Float it gives 60ns of precision at the end of each second, and more precision near the beginning of each second. With Double it's about 2e-16 s at the worse end of a second. In my language the internal representation is like Haskell's Integer, counting ticks of implementation-defined resolution (available as a constant), which is nanoseconds in the only implementation so far, but I don't want to set a limit in stone. It's rarely visible to the user though. A difference between two times is presented as a number of seconds stored in Double. So the absolute time is in fixed point (constant precision) and relative time is floating point (convenient for computation in the human-friendly unit of a second). -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/