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