System.Time.Clock Design Issues
seth at cql.com
Thu Feb 3 15:54:42 EST 2005
One thing that I think is worth looking at is the way that the GPS
satellites represent time. It has a different epoch, and rolls over,
which are both negatives, but it also has an interesting way of handling
On the subject of a leap second table, the table can get out of date not
just because time has passed, but because the decision to add an
additional leap second is occasionally made, so even if your table's
_date_ is not stale (that is, your leap second time should be good, say,
for today) that doesn't guarantee that it is correct. This has only
happened once AFAIK, but I've not worked on the GPS satellites in some
time so that information may be out of date.
Basically, GPS time is a pair of values, one being the current time as
if leap seconds never occur, which means it is one additional second
behind each time a leap second occurs. The second number is the total
number of leap seconds. No table, just one value, which can be
incremented when necessary.
You still have to know that it needs to be incremented, but that (IMO)
is sufficiently simple that it can be left to the user between GHC releases.
Simon Marlow wrote:
>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.
>Libraries mailing list
>Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries