To correct my own email, there is no table required for the _current_ time. If the previous time is given in GPS, then there is also no need for a table for intervals. Calendar time is another issue. Seth Kurtzberg wrote:

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 leap seconds.

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" 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 _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

!DSPAM:4202934b17281632058756!

------------------------------------------------------------------------

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

!DSPAM:4202934b17281632058756!