System.Time.Clock Design Issues
simonmar at microsoft.com
Thu Feb 3 12:15:30 EST 2005
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.
More information about the Libraries