Marcin 'Qrczak' Kowalczyk
qrczak at knm.org.pl
Wed Jan 26 13:26:38 EST 2005
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
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
More information about the Libraries