Difficulties with libTAI

[calvin.harman@…]

After working with libTAI for the past few days, I've encountered several
issues which may justify not using it. I've listed problem areas below and
provided a possible alternative.

1. Cumbersome to install. The make process for libTAI is simple, but the user

must follow instructions in the INSTALL file after making the library to
complete installation. These instructions require the user to create a binary
data file from a text file and copy it to another system directory, and also
run several tests to insure that the data file is correct version. If the data
file is incorrect or fails the install tests, you have to find a corrected data
file on the internet.

2. Untested. The current version of libTAI is an alpha version and has not been

fully tested. The author states this in the INSTALL file, and even says that
some code has not been tested at all.

3. Uncorrelated results. libTAI results don't agree with with International

Bureau of Weights and Measures (bipm.org) value of TAI time. Using libTAI's
taia_now() function to get the current TAI time adds 10 sec to the current
timeval (UTC time) time, which is incorrect. It should add 32 seconds, since
UTC time currently lags TAI time by 32 seconds. Also, when using the caltime_utc
() function to convert from TAI time to UTC time, the resulting UTC time ends
up 22 seconds behind current UTC time.

4. Clock resolution. libTAI can't provide attosecond accuracy. Even though it

provides a few algorithms for manipulation of an attosecond structure member,
these do not enter into the mainstream libTAI conversion functions. The taia_now
() function is responsible for calculating initial time values, but currently
sets attoseconds to zero and also bases the the nanosecond calculation on
timeval's microseconds value. Since many computer platforms only support timing
accuracy to microseconds, the attosecond functionality turns out not to be very
useful.

5. TAI time changes/jumps occasionally. Every few years TAI time changes to add

a leap second to UTC time. Predicting when this change occures is not possible,
since it is based on the Earth's rotation rate and the movement of Earth's
continental plates. It originally increased by a second every few months, but
stopped being increased in 1998 when it was determined that the Earth's crust
was accelerating to compensate for the TAI time offset. If TAI time does
increase again in the future, it would be the responsibility of individual
psLib users to locate and install the correct data file with the new leap
second data.

Based on what I've learned so far, my recommendation would be to not use
libTAI. I'd recommend staying with the more standard timeval (UTC) calculation.
If TAI time is still desired, then a conversion to TAI time could be created,
which simply adds 32 seconds to UTC time. If TAI time jumps to 33 seconds in
the future, users would simply change a constant and recompile, as opposed to
going through the libTAI configuration process.

[jhoblitt]

In response to Ross's numbered points:

1. I agree that this can be a pain but the process is going to be similar for

any library that properly supports UTC.

2. I agree that it claiming to be alpha grade software is a bit worrying.

3. It looks like taia_now() makes a funny assumption. From the taia_now(3) man

page:

"NOTES

This implementation of tai_now assumes that the struct timeval returned
from gettimeofday represents the number of TAI seconds since 1970-01-01
00:00:10 TAI."

This isn't terribly important as we will rarely want to generate a high
percision timestamp and if we did it's easy enough to use gettimeofday(2)
directly and convert it.

4. While PC hardware can't generate attosecond precision that doesn't mean we

won't be dealing with better then microsecond precision timestamps generated by
other systems. We just care that the conversions are being done *correctly*.

5. There is generally a six month warning before before a new leapsecond is

introduced to UTC. Just because it is a pain to update the leap-second library
doesn't mean we can be ignorant of this issue. If we end up using another
library or writing our own we will still be stuck with this responsibilty.

Your suggestion of using a fixed offset just won't work for all of the potental
users of psLib (including astrometry for PS1). Anyone processing data from
before 1999-01-01 would have to contend with suttle errors.

Ps. The TAI-UTC offset could just as easily change to 31 seconds

[eugene]

Ross and I have discussed this and have decided to do the following:

1) define the psTime structure as equivalent to the basic timeval struct:

typedef struct {

time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */

} psTime;

2) specify the scale of psTime to be SI (like both UTC and TAI)

3) specify the zero of psTime to be 1970/1/1,00:00:10 (equivalent to timeval,
but with the correct zero for TAI).

4) pre-compile a table of leap-seconds.

these are somewhat temporary solutions, but by placing the time functions in one
location we can work with these and defer choosing a more robust solution.

[Paul Price]

libTAI has been dropped, and we now use our own psTime structure, much as Gene
specified. Significant changes to the psTime functions in SDRS-06 have been made.