Time Resolution

[Ben Rudiak-Gould]

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.

-- Ben