We use the file tai-utc.dat (which is obtained by

wget http://maia.usno.navy.mil/ser7/tai-utc.dat

) to define the relationship between UTC and TAI.  (That file gets updated
once per year or so, and it is the PLplot release manager's
responsibility to check that the local tai-utc.dat is up to date with
the file at maia.usno.navy.mil.)  Here are the first and last lines in
this file (as of 2009-03).

 1961 JAN  1 =JD 2437300.5  TAI-UTC=   1.4228180 S + (MJD - 37300.) X 0.001296 S
 2009 JAN  1 =JD 2454832.5  TAI-UTC=  34.0       S + (MJD - 41317.) X 0.0      S

Clearly, the JD where the discontinuity in UTC occurs is in UTC.  (If
it were in TAI instead, the JD epoch would not correspond to midnight
exactly.)  I further assume that for early epochs where there was a
non-zero slope, the MJD argument is also UTC.  Thus, we have the
following general relationship that holds between the discontinuities in UTC.


MJD(TAI) - MJD(UTC) = (offset1 + (MJD(UTC) - offset2)*slope)/86400    (1)

The tai-utc-gen application reads in these (UTC) epoch, offset1, offset2,
and slope data from tai-utc.dat, calculates the discontinuous change in UTC
at the unique TAI epoch of the UTC discontinuity using equation 2 below, and
stores the results in the header file tai-utc.h as the TAI_UTC_lookup_table
with data for MJD(TAI) (int base_day, double time_sec_tai), MJD(UTC) (int
base_day, double time_sec_utc = 0.), the discontinuous change, offset1,
offset2, and slope stored for each epoch.

The qsastime library uses equation 1 to calculate MJD(TAI) as a
function of MJD(UTC), and

MJD(TAI) - MJD(UTC) = ((offset1 + (MJD(TAI) - offset2)*slope)/86400)/
	   	      (1. + slope/86400)                              (2)

to calculate MJD(UTC) from MJD(TAI).  (Equation 2 can be derived from
equation 1 by adding (MJD(TAI) - MJD(UTC))*slope/86400 to each side
and dividing out the common factor.)  The data for these two equations
is taken from tai-utc.h, and the efficient routine bhunt_search is used to
find for a given MJD(TAI) or MJD(UTC) which set of data to use for the
transformation from TAI to UTC or vice versa.

For historical epochs prior to the starting date of tai-utc.dat
(1961-01-01 = JD 2437300.5 UTC) we assume the same TAI-UTC offset of
1.422818 seconds as for the starting date of that file.  This
assumption of no variation in the earth rotation rate prior to 1961 is
obviously not correct so that the TAI, TT, etc. derived from our code
will not be reliable prior to that date.  That is, if you use GMT (a
historical backwards extension of UTC corresponding to civil time for
the prime meridian) for broken down time prior to 1961, the TT result
you will get will not produce a good approximation to the historical
ephemeris time that is the correct backwards extension of TT, see
http://en.wikipedia.org/wiki/Ephemeris_time.

For epochs after the ending date of tai-utc.dat (currently 2009-01-01
= JD 2454832.5 UTC) we assume the same TAI-UTC offset (currently 34
seconds) as for the ending date of that file, i.e., we assume no leap
seconds after the ending date of the file. Insertion of leap seconds
cannot be predicted years in advance (because future predictions of
the earth rotation rate are not reliable on such time scales) so the
transformation between civil time (UTC) and TAI, TT, etc. cannot be
known years in advance.  However, the approximation of assuming no
leap seconds after the end of the file should be correct on time
scales less than roughly a year so when a decision is made in advance
to insert an official leap second, there should be plenty of time for
that decision to propagate to
http://maia.usno.navy.mil/ser7/tai-utc.dat and ultimately the
tai-utc.dat file included in our code releases. Thus, so long as we
make releases on a timely basis, our calculation of TT for current
epochs should always be reliable.