System.Time.Clock Design Issues

[Seth Kurtzberg]

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