Time Libraries Rough Draft

[Aaron Denney]

On 2005-02-12, David Menendez <zednenem at psualum.com> wrote:
> Daan Leijen writes:
>
>> clock: measures passage of absolute time (time difference). Best       
>>     available unit is (TAI) SI seconds (ie. cesium atom
>>   oscillations)
>> 
>> calendar: gives time *stamps* to human related notion of time. Can be
>>             used to calculate calendar time differences, ie. human
>>             notions of time difference, like days and months, and yes,
>>             *calendar* seconds (ie. not absolute SI seconds).
>> 
>> TAI is a clock. Sometimes they give it as date, but really, it is just
>> SI-seconds since some epoch (specified as an UTC calendar date!)
>
> This could be correct, but my understanding is that TAI and UTC are both
> calendars that are based on the same clock. The difference is that the
> UTC clock/calendar conversion requires a leap-second table and the TAI
> conversion does not.

It's one way of looking at it, but not the most insightful, IMO.  The
"dates" that TAI provides need bear no relationship to the times and
days we're comftorable with.

> The problem is that NTP is based on a different clock

True.

> where some seconds are longer than others.

No.  NTP time is a straight count of SI seconds, and includes
information about whether there is a leap second in the current day,
but _drifts_ the epoch against which it is defined by the number of leap
seconds that have passed.

rfc1305> The NTP timescale is based on the UTC timescale, but not
rfc1305> necessarily always coincident with it.  At 0h on 1 January
rfc1305> 1972 (MJD 41,317.0), the first tick of the UTC Era, the NTP
rfc1305> clock was set to 2,272,060,800, representing the number of
rfc1305> standard seconds since 0h on 1 January 1900 (MJD 15,020.0). The
rfc1305> insertion of leap seconds in UTC and subsequently into NTP
rfc1305> does not affect the UTC or NTP oscillator, only the conversion
rfc1305> to conventional civil UTC time. However, since the only
rfc1305> institutional memory available to NTP are the UTC timecode
rfc1305> broadcast services, the NTP timescale is in effect reset to
rfc1305> UTC as each timecode is received. Thus, when a leap second
rfc1305> is inserted in UTC and subsequently in NTP, knowledge of all
rfc1305> previous leap seconds is lost.  Another way to describe this
rfc1305> is to say there are as many NTP timescales as historic leap
rfc1305> seconds.  In effect, a new timescale is established after
rfc1305> each new leap second.  Thus, all previous leap seconds, not
rfc1305> to mention the apparent origin of the timescale itself, lurch
rfc1305> backward one second as each new timescale is established. If
rfc1305> a clock synchronized to NTP in 1990 was used to establish the
rfc1305> UTC epoch of an event that occurred in early 1972 without
rfc1305> correction, the event would appear fifteen seconds late
rfc1305> relative to UTC. However, NTP primary time servers resolve
rfc1305> the epoch using the broadcast timecode, so that the NTP clock
rfc1305> is set to the broadcast value on the current timescale. As a
rfc1305> result, for the most precise determination of epoch relative
rfc1305> to the historic UTC clock, the user must subtract from the
rfc1305> apparent NTP epoch the offsets shown in Table 8 at the relative
rfc1305> epoches shown. This is a feature of almost all present day
rfc1305> time-distribution mechanisms.

(note that rfc 1305 uses "epoch" differently than the standard in Unix.
For NTP, epoch is the reading of some clock at some specific point in
time, not the zero of a count of time-units.)

NTP client _implementations_ on _POSIX systems_ slow down the local clock
slightly for a few minutes before the transition.

This is entirely due to POSIX UTC being unable to represent the correct
time, and wanting to skip directly from 11:59:59 to 12:00:00, rather
than going through 11:59:60, and deciding that slowing down the clock is
better than repeating a second.

>> Now what I understand about implementation:
>> 
>> - gettimeofday() returns the number of seconds since epoch (a UTC
>> date)
>> 
>> What kind of seconds does it return?  Well, (A) sometimes these are
>> just SI-seconds (which means we can derive TAI from that), but
>> sometimes (B) it returns UTC-seconds -- ie. the absolute SI-second
>> count, plus/minus any leap seconds that have occurred.
>
> I think you mean "POSIX-seconds" instead of "UTC-seconds" here.
> Otherwise, (A) and (B) seem identical to me.

UTC POSIX seconds, or NTP seconds, or (UTC days/86400) + number of
seconds that have passed in the current day.

-- 
Aaron Denney
-><-