On 2005-02-12, David Menendez
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 -><-