Ashley Yakeley wrote:

In article <eg1xc2ovdt.fsf@frynseeik.ii.uib.no>,
 Ketil Malde <ketil+haskell@ii.uib.no> wrote:

It would be nice if the interface was such that it didn't matter to
the user.  Couldn't it be an opaque type?  And does the resolution
have to be standardized?  Standardizing on picoseconds is probably
safe, but I think it would be better to be able to query about the
underlying clock resolution, instead of getting a long sequence of
non-significant digits.


Bear in mind that the time type might be used for time calculations 
unrelated to the system clock. Whether or not we hide the constructor, I 
think its internal resolution and general behaviour ought to be known 
and platform-independent.

I understand what Ashley is saying, but that type of calculation is very different from a calculation related to the system clock.

The choices that seem to be on the table here are flawed. To force all time calculations to be no better than the system clock resolution is not sensible, for the reasons that Ashley states. However, it is also not acceptable for a function to return an incorrect value for calculations involving the system clock.

If, say, I make two calls to read the current time, and both return the same value, what does that mean? Clearly it doesn't mean that no time has passed. It means that the clock hasn't ticked, but it provides no information about exactly what that means. Does it mean that the elapsed time is less than a second? A millisecond? A microsecond? Without knowledge about the resolution of the system clock, there is no way to find out.

I think that this particular pair of birds can't be killed with one stone. The system clock resolution is platform dependent, and this fact must be dealt with in a way that doesn't produce incorrect answers. Time values whose source is the system clock are different not only in resolution but also in kind. As presented, the choice is between having a cripled library that is a slave to the system clock resolution, or having a useful computational capability for time but returning incorrect answers w.r.t. the system clock.

Clearly these are two different things. The core of the time calculation can be shared by these two different types of time, but at the user level it needs to be clear whether a value is derived from the system clock, or is not. I don't see any way around the need for a different interface for each. The alternatives are unacceptable.