System.Time.Clock Design Issues

[Seth Kurtzberg]

Ashley Yakeley wrote:

>In article 
><r02010400-1037-20A8A440798C11D9A333000393758032@[10.0.1.2]>,
> David Menendez <zednenem at psualum.com> wrote:
>
>  
>
>>As I understand it, TAI and UTC can both be described in terms of a
>>clock counting SI seconds. The difference is that a TAI day is always
>>86400 seconds long, whereas a UTC day can be 86399 - 86401 seconds,
>>depending on which second it is.
>>    
>>
>
>Yes.
>
>  
>
>>Using TAI, we can always convert a date and clock time to a count of
>>seconds and vice-versa without any additional information. To do the
>>same with UTC, we need a table of leap-seconds.
>>    
>>
>
>No. Date and clock times are usually UTC or some offset (time-zone) 
>thereof. Converting to TAI requires a table of leap-seconds.
>
>  
>
I mentioned this before, but it may have been lost in the shuffle.

GPS has a clever way of handling leap seconds even though they are not 
known in advance.  GPS receivers properly handle leap seconds, without 
firmware updates, even though the specifics (when each leap second 
occurs) are now known in advance.

The general idea is that TAI time is accompanied by a value which is the 
current difference between TAI and UTC.  That in itself is interesting, 
but more interesting is the fact that it can go both forwards and 
backwards without a leap second table.

This URL has technical information:  
http://tycho.usno.navy.mil/gps_faq.html  The site is a bit old, but the 
information is still current.  It indicates that leap seconds are not 
the only corrections that are used.  The latest unit for the time 
library (latest I've seen in this thread) is nanoseconds.  The URL 
explains additional corrections required to keep nanosecond time.

This may well be overkill for our purposes, but it doesn't hurt to look.