System.Time.Clock Design Issues

[Seth Kurtzberg]

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" <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
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries
>
>!DSPAM:42025fe3180241961954109!
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/libraries/attachments/20050203/8617ce54/attachment-0001.htm