Benjamin.Rudiak-Gould at cl.cam.ac.uk
Tue Feb 1 08:43:16 EST 2005
Aaron Denney wrote:
>[...] If we were to use the posix timer CLOCK_REALTIME
>with clock_gettime(), then clock_getres() should would give us the
>precision, but not, of course, the accuracy.
I agree with everything you wrote, and I think it's worth making a big
deal of the fact that precision and accuracy are different things,
because it's easy to confuse them in discussions like this. Every
time-related system call specifies a precision, but I don't think any of
them say anything about accuracy.
Furthermore, on nearly every system the differential accuracy of a
system clock will be orders of magnitude better than its absolute
accuracy, so it's ambiguous to talk about accuracy without specifying
which one you mean.
Yet another distinct concept is that of a time interval like "1 February
2005 UTC", which has infinite precision and accuracy even though it's
fuzzy in a different way. It doesn't make sense to represent the day
with picosecond precision because then you're effectively talking about
a particular picosecond in that day, which is a totally different concept.
Possibly we could get away with talking always about intervals of time
(rather than points), but allowing intervals of different sizes. E.g.
(trying to retain static typing here):
newtype AbsPicoseconds = AbsPicoseconds Integer
newtype RelPicoseconds = RelPicoseconds Integer
newtype AbsSeconds = AbsSeconds Integer
newtype RelSeconds = RelSeconds Integer
newtype AbsDays = AbsDays Integer
newtype RelDays = RelDays Integer
Conversions from AbsPicoseconds to AbsSeconds to AbsDays may make sense,
but the reverse don't. And no conversions on Rel times make sense.
These data types don't carry accuracy information around with them,
because I think that's hopeless.
More information about the Libraries