System.Time.Clock Design Issues

[Ashley Yakeley]

On Feb 3, 2005, at 04:09, Simon Marlow wrote:

> That's a good way to put it.
>
> I think TAI + calendar time covers all the bases, except that you can't
> do *really fast* second-based calculations that ignore leap seconds.
> But (a) I don't think this is something we should encourage and (b) I
> don't think we should expose an inherently wrong representation of time
> (i.e. POSIX).

It's true that POSIX is an inherently wrong representation of UTC, as 
it is wrong at leap seconds. The trouble is, what you are suggesting is 
a type that is wrong in a much more complicated way: it starts off as a 
correct representation of TAI, and turns into a representation of UTC 
that is also wrong at leap seconds.

Let us suppose we have a system clock that keeps POSIX time, and a 
Haskell function, getClockTime, that returns the current ClockTime you 
are suggesting. I compile a program that calls this function.

At first getClockTime returns the correct TAI time, which can be 
converted into the correct UTC time. Then, in two years' time, a leap 
second is announced. During the leap second, the system clock is 
stepped, and getClockTime returns the wrong TAI time converted to the 
wrong (by up to a second) UTC time. After the leap second, getClockTime 
continues to return the wrong TAI time, but it is converted to the 
correct UTC time.

What we end up with is a type that no longer represents TAI. Instead, 
it represents a fixed offset to UTC. The only way to get anything 
correct out of it is to convert it to UTC, though even then, it won't 
be correct during a leap second -- exactly like POSIX time.

It's the same if we wish to measure time offsets. Supposing I want to 
know how long something takes, of the order of seconds. I call 
getClockTime at the beginning and end of the interval, and subtract one 
from the other. This will be correct most of the time, but if there was 
a leap second in between, which the library cannot predict if my 
program was compiled years ago, then the calculation will be off by a 
second. Again, this is exactly like POSIX time.

So what we have is a type that behaves like TAI for the past, but POSIX 
time for the future, even though it's supposed to be TAI. Surely it 
would be better to simply use POSIX time?

-- 
Ashley Yakeley, Seattle WA