System.Time.Clock Design Issues

[Simon Marlow]

On 03 February 2005 13:01, Ashley Yakeley wrote:

> 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.

Actually you'd probably get a correct UTC time, because the conversion
would be done by first converting to POSIX time, and then asking the C
library to convert to UTC.  The errors cancel out.

But I agree with the rest of what you say.  Basically, providing TAI
time is problematic because we can't implement it correctly, for future
times, on systems that only provide POSIX time.

At this point I'm not sure what is best, I'm still quite disturbed by
the idea of basing the definition of the Haskell Time library on what is
basically a mistake in the definition of POSIX :-)

Cheers,
	Simon