Time

[Marcin 'Qrczak' Kowalczyk]

Peter Simons <simons at cryp.to> writes:

> 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 at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/