RE: System.Time.Clock Design Issues

On 03 February 2005 16:32, Scott Turner wrote:

 "Simon Marlow" wrote:

...

You can still do accurate calculations on calendar times in the future, and that's what matters.

However, the relationship between seconds and the future calendar is not known. A specific second such as 2005-12-31T23:59:59 may turn out not to occur. So even CalendarTime is not safe from leap seconds.

Yes, I was aware of that but trying not to confuse the issue too much (I mentioned it in a later message).

On 2005 February 03 Thursday 08:00, Ashley Yakeley wrote:

...

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.

Until there's a system call that provides up-to-date information about leap seconds, the above-quoted scenario can occur. Since future conversions between calendar time and TAI are likely incorrect, how about raising an exception?

Actually I very nearly proposed that in an earlier message. You could also do the slightly less drastic: canConvertAccuratelyToCalendarTime :: TAI -> IO Bool and the reverse. Cheers, Simon