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