System.Time.Clock Design Issues

[Simon Marlow]

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

>  "Simon Marlow" <simonmar at microsoft.com> 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