The relationship between different timestandards and labels is somewhat
complex. The following web sites contains further information about
these different time standards:
ftp://tycho.usno.navy.mil/pub/series/ser14.txt
ftp://tycho.usno.navy.mil/pub/series/ser14.txt
ftp://maia.usno.navy.mil/ser7/taiutc.dat
ftp://maia.usno.navy.mil/ser7/taiutc.dat
http://tycho.usno.navy.mil/time.html .
http://tycho.usno.navy.mil/time.html
What is presented here is merely a summary for the perplexed.
The situation is complicated slightly because on standard Unix machines
(Solaris 2.6, Linux 2.0*, etc) the time functions in the ``ANSIstandard C
library" do not behave according to the rather vaguelydefined ANSI/POSIX
standards. (In particular, the gmtime() function in the C standard
library does not know about leapseconds  although the documentation
generally suggests that it should!)
Let us begin by defining a physical time , which is the time coordinate used in physics lectures. It advances linearly, completing each unit step at the same instant that a perfect pendulum with a frequency of 1 Hz completes a new oscillation. Without loss of generality we will set at the stroke of midnight, January 1, 1970 UTC. This time is also denoted Jan 1 00:00:00 UTC. Note that we will not discuss local time in this section, which differs from UTC by a fixed number of hours that depend upon your timezone and upon whether or not daylight savings time is in effect. We will assume that once you know the UTC time, you can do the necessary addition or subtraction yourself, to determine local time at any point of interest on the earth.
Universal Coordinated Time (UTC), Global Positioning System (GPS) and International Atomic Time (TAI) are all welldefined global standards. By UnixC time we mean here the value of . This is what is returned by the Standard Clibrary time() function, which advances its output by one every second, starting from Jan 1 00:00:00 UTC, provided that the computer is started at Jan 1 00:00:00 UTC and runs continuously and without error after that. (See below for an explanation of why this qualification is required!)
UTC should be thought of as a system for attaching "human readable" labels such as ``March 11, 1983, at 12:10" to particular moments in time. (We use ``military" or 24hour time to distinguish am and pm.) This is done by advancing in the standard pattern of 1 hour every 3600 seconds, one day every 24 hours, and so on, with two exceptions. These exceptions are necessary because if they were not made, eventually people in the northern hemisphere would be suffering snowfalls in August.
The first of the two exceptions is easy. Once every four years, according to the pattern 1972, 1976, ... there is a leap year, which is a year containing one extra day. In these years, February has 29 days not 28. This affects the pattern by which UTC time follows , and is a minor nuisance. However, because it follows a regular deterministic pattern, leap years with their extra day present no real problems.
The real complications arise because the earth is gradually slowing in its rotation about its axis, from the effects of earthmoon and earthsun tidal friction, and because the sunspot cycles affects the heating of the earth and thus its mass distribution and moment of inertia. These effects are not easily predicted in advance, and thus on a regular basis (between once every two years and twice a year) an extra second is inserted into the UTC label. The decision about when to do this is made by the International Earth Rotation Service (IERS) http://hpiers.obspm.fr/. http://hpiers.obspm.fr/ This one extra second is generally added right after what would be the final second of a month (generally December or June). Thus, at these times, the normal pattern of ..., 23:59:58, 23:59:59, 00:00:00 ...is broken and replaced by ..., 23:59:58, 23:59:59, 23:59:60, 00:00:00, ... . The next leap second will be inserted into UTC in this way at the end of December 1998. In principle, a leap second can be either positive or negative, although there have not yet (as of September 1998) been any negative leap seconds.
Unfortunately, there is one additional small complication. Until Jan 1, 1972 UTC, the duration of one UTC second was not equal to the duration of one (physical, TAI=GPS=CTime) second. This can be seen most easily from ftp://maia.usno.navy.mil/ser7/taiutc.dat ftp://maia.usno.navy.mil/ser7/taiutc.dat. Here is a small extract from that file.
... 1966 JAN 1 =JD 2439126.5 TAIUTC= 4.3131700 S + (MJD  39126.) X 0.002592 S 1968 FEB 1 =JD 2439887.5 TAIUTC= 4.2131700 S + (MJD  39126.) X 0.002592 S 1972 JAN 1 =JD 2441317.5 TAIUTC= 10.0 S + (MJD  41317.) X 0.0 S 1972 JUL 1 =JD 2441499.5 TAIUTC= 11.0 S + (MJD  41317.) X 0.0 S 1973 JAN 1 =JD 2441683.5 TAIUTC= 12.0 S + (MJD  41317.) X 0.0 S ...Here, the Modified Julian Day (MJD) is defined as follows: MJD = JD  2400000.5, where the Julian Day increments by one at noon every day. Notice that these relationships imply that, before January 1, 1972 UTC, the difference between atomic time (TAI) and UTC time is not an integer number of seconds!
The values of JD and MJD at some interesting times are given below
1968 Feb 1 00:00:00 UTC JD=2439887.5 MJD=39887 1969 Feb 1 00:00:00 UTC JD=2440253.5 MJD=40253 1970 Jan 1 00:00:00 UTC JD=2440587.5 MJD=40587 1970 Feb 1 00:00:00 UTC JD=2440618.5 MJD=40618 1971 Jan 1 00:00:00 UTC JD=2440952.5 MJD=40952 1972 Jan 1 00:00:00 UTC JD=2441317.5 MJD=41317In particular, on Jan 1 00:00:00 1970 UTC, the formula above gives:
Much of the complication arises because the standard Unix Clibrary function gmtime(), which takes as its argument the number of seconds after Jan 1, 1970 UTC, and should return the UTC time, does not return the correct UTC time. The function gmtime() fails to take account of leap seconds. The relationship between , UnixC time, and UTC time is demonstrated in the table below, which shows the effects of the leap seconds and the erroneous behavior of gmtime(). Note that in this table, the definition of ``leap second" is not made precise until on or after Jan 1, 1972 UTC. Until that time, the number of leap seconds can be noninteger: here we have assumed that it is integer. (This is of no consequence provided that we only study the relationship between our different time standards for times after Jan 1, 1972 UTC).

The most easily used time standard today is GPS time, because GPS
receivers are cheap, accurate, and available. GPS time is equal to
plus a constant. GPS was set to be zero on Jan 6 00:00:00 1980 UTC.
Hence
.
This is because, up to the 82 microseconds mentioned in equation (),
one has
(17.0.336) 
(17.0.337) 
(17.0.338) 
(17.0.339) 
The final time coordinate in general use is TAI = GPS + 19 sec. This obeys the relationship
(17.0.340) 
The GRASP library contains a pair of utility functions utctime() and gpstime() which are similar to gmtime(), except that they correctly generate the UTC label for UnixC time and GPS time (respectively).
Because the number of leap seconds is not know in advance (we can not
predict how the earth's rotation rate will change in the future) it is
often useful to store in time records both a physical time label (for
example GPS time) and in addition the number of leap seconds, in the form
(TAIUTC). Because the UnixC library function gmtime()
is broken, we can use it to print the correct ``humanreadable" UTC
times almost all of the time, by using:
(17.0.341) 