<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Simon Marlow wrote:
<blockquote
cite="mid3429668D0E777A499EE74A7952C382D103190C59@EUR-MSG-01.europe.corp.microsoft.com"
type="cite">
<pre wrap="">On 03 February 2005 16:32, Scott Turner wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> "Simon Marlow" <a class="moz-txt-link-rfc2396E" href="mailto:simonmar@microsoft.com"><simonmar@microsoft.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">You can still do accurate calculations on calendar times in the
future, and that's what matters.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, I was aware of that but trying not to confuse the issue too much (I mentioned it in a later message).
</pre>
<blockquote type="cite">
<pre wrap="">On 2005 February 03 Thursday 08:00, Ashley Yakeley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://www.haskell.org/mailman/listinfo/libraries">http://www.haskell.org/mailman/listinfo/libraries</a>
!DSPAM:42025fe3180241961954109!
</pre>
</blockquote>
<br>
</body>
</html>