TIME STANDARDS
UT0 - time standard based on astronomical observations.
UT1 - more precise version of astrononical time based on corrected UT0. This was once called GMT. Now GMT is a only time zone and not a time standard.
UTC - (Universal Time, Coordinated) In 1958 the US Naval Observatory established A1 or "Zulu" time using atomic clocks with the time coordinated with the Greenwich observatory. In 1967, a second was defined as 9,192,631.770 oscillations of a specific radiation from cesium 133. Until the end of 1971 the time was adjusted to match the earth's rotation when it was about 1/10 second "out of sync." On 1 Jan 1972, the system was changed and atomic time took over. This is UTC.
When UTC is out of synch with UT1, a leap second is added (or removed) to UTC.
Leap Seconds
According to The National Institute of Standards and Technolgy (NIST) a leap second is a second added to Coordinated Universal Time (UTC) to make it agree with astronomical time (UT1) to within 0.9 second. UTC is an atomic time scale, based on the performance of atomic clocks. Astronomical time is based on the rate of rotation of the earth. Since atomic clocks are more stable than the rate at which the earth rotates, leap seconds are needed to keep the two time scales in agreement. We now set our watches and calendars by UTC. UTC runs slightly faster then UT1. If leap seconds were not occasionally added, physical phenomena like sunrise, noon, and sunset would happen later and later. Note that the insertion of the leap second to UTC has the same effect as stopping UTC clocks for one second allowing astronomical time (UT1) to "catch up".
Watching the seconds field of a digital clock tick past a leap second, your would see:
:58 - :59 - :60 -:00 -:01
whereas, an normal minute boundary would look like:
:58 - :59 -:00 -:01
The first leap second occurred on June 30, 1972. There have been a total of 23 leap seconds between the beginning of the system and December, 2005. This means that leap seconds occur approximately every 18 months. However, there were seven years between the 1998 and 2005 leap seconds. It is possible to have a negative leap second (a second removed from UTC), so far, all leap seconds have been positive (a second has been added to UTC). Based on what we know about the earth's rotation, it is unlikely that we will have a negative leap second in the foreseeable future. According to the definition of leap seconds it is possible for two leap seconds to be applied at once. This has never occured and is very unlikely to ever occur.
The last leap second was inserted at 23:59:60 UTC on December 31, 2005. It made the last day of December one second longer than normal. Note that IERS documents this leap second as having occured on January 1, 2006 (see table below).
List of leap second insertion times (year mo dy):
The decision to introduce a leap second in UTC (or not) is announced six months in advance in Bulletin C of the International Earth Rotation Service (IERS). According to international agreements, first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September. Since the system was introduced in 1972, only dates in June and December have been used. A proposal has been made to abolish the use of leap seconds. The issue is undecided.
Confusion sometimes arises over the misconception that the regular insertion of leap seconds every few years indicates that the Earth should stop rotating within a few millennia. The confusion arises because some mistake leap seconds as a measure of the rate at which the Earth is slowing. The one-second increments are, however, indications of the accumulated difference in time between the two systems. As an example, the situation is similar to what would happen if a person owned a watch that lost two seconds per day. If it were set to a perfect clock today, the watch would be found to be slow by two seconds tomorrow. At the end of a month, the watch will be roughly a minute in error (thirty days of the two second error accumulated each day). The person would then find it convenient to reset the watch by one minute to have the correct time again. It does not mean that the slow watch will eventually stop.
Leap seconds and GPS time.
Raw GPS time is NOT adjusted for leap seconds and is, therefore, out of synch with UTC by the number of seconds since the GPS epoch time of January 6, 1980. The offset is given in the NAV message and the receiver should apply the correction automatically. As of July 1, 1997, GPS time is ahead of UTC by twelve (12) seconds. Absolute time will not deviate by more than one microsecond and is usually better then 200 nanoseconds .
Epochs
Epoch is the starting point from which you measure elapse time. Every time system boils down to an epoch (or multiple epochs) and some elapse time unit that is counted after the epoch. For example our common time system has multiple epochs and units; years since birth of Christ, months since start of year, days since start of month, hours since start of day, minutes since start of hour, seconds since start of minute. This is what makes it so complex.
Storing year, month, day, hour, minute, second (ymdhms) is wasteful
of computer storage and makes sorts and compares computationally expensive.
Most computer time systems solve this problem by counting seconds since
some recent epoch. Here is a list of some existing computer epoch start
time:
| Unix Epoch | 00:00 January 1, 1970 | |
| Microsoft | 00:00 January1, 1983 (?) | |
| Julian Date | 00:00 January 1, -4712 (4713 BC) | |
| Smithsonian
Modified Julian Date |
00:00 November 17, 1858 | |
| Macintosh | 00:00 January 1, 1904 | |
| GPS | 00:00 January 6, 1980 | |
Counting Elapse Time Past the Epoch
Counting elapse minutes would increase you range to about 4,080 years. This would provide suffient range for seismological data given a reasonable epoch. The seconds portion of the time would need be be stored seperately. A float value would be sufficient but would introduce complexity because of the different float representations that exist. An additional signed long integer could be used to give elapse time within the minute. This would allow a precision of 1/2,147,483,647 minutes or 0.000000028 seconds. This would easily handle units of 10-6 seconds (microseconds) or 10-3 seconds (milliseconds).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NTP time
All mathematical operations assumed in the protocol are two's-complement arithmetic with integer or fixed-point operands. Since NTP timestamps are cherished data and, in fact, represent the main product of the protocol, a special format has been established. An NTP timestamp is a 64-bit unsigned fixed-point number, with the integer part in the first 32 bits and the fraction part in the last 32 bits and interpreted in standard seconds relative to UTC. When UTC began at 0h on 1 January 1972 the NTP clock was set to 2,272,060,800.0, representing the number of standard seconds since this time at 0h on 1 January 1900 (assuming no prior leap seconds).
This format allows convenient multiple-precision arithmetic and conversion to other formats used by various protocols of the Internet suite. The precision of this representation is about 232 picoseconds, which should be adequate for even the most exotic requirements. Note that since some time in 1968 the most significant bit of the 64-bit field has been set and that the field will overflow some time in 2036. Should NTP be in use in 2036, some external means will be necessary to qualify time relative to 1900 and subsequent 136-year cycles. Historic timestamped data of such precision and requiring such qualification will be so precious that appropriate means should be readily conceived.
Timestamps are determined by copying the current value of the local clock to a timestamp variable when some significant event occurs, such as the arrival of a message. In some cases a particular variable may not be available, such as when the server is rebooted or the protocol is restarted. In these cases the 64-bit field is set to zero, indicating an invalid or undefined value. There exists a 232-picosecond interval, henceforth ignored, every 136 years when the 64-bit field will naturally become zero and thus be considered invalid.