The Neil Gehrels Swift Observatory

Guide to Times in Swift FITS Files

Times in the uncorrected TIME columns of Swift FITS files are Mission Elapsed Time (MET), in seconds. The time system in the header keywords is "TT"- Terrestrial Time, an IAU standard time scale since 1984, synchronous with (but 32.184 s ahead of) International Atomic Time (TAI). This is recorded in the TIMESYS keyword.

The reference date for Swift is January 1, 2001, UTC. This is reflected in the reference keywords. The value of MJDREFI + MJDREFF is the epoch January 1.0, 2001, expressed in the TT time system. The integer and fractional keywords are maintained separately for full numerical precision. It is also true that MJDREFF is the offset in days between UTC and TT on January 1, 2001. The keywords appearing in Swift FITS files are shown below.

TIMESYS = 'TT  ' / indicates the time system of the file
MJDREFI = 51910
MJDREFF = 7.4287037E-4
CLOCKAPP = F / clock correction has not been applied

Here, CLOCKAPP = F means that no attempt has been made to correct the times in the TIME column of the file.

It is expected that the spacecraft clock will be set once, soon after launch, and be free-running thereafter. As the clock drifts, the MOC will track the difference between MET on the spacecraft and the true UTC. The difference is uploaded to the spacecraft and referred to as "UTCF" (the UT correction factor). The current value of UTCF onboard Swift is telemetered along with the data and available to the MOC and SDC. If the true UTCF were a well-known (or well-modeled) function of time, then one could correct the MET back to UTC by adding UTCF at each timestep, Thus, for Swift FITS files with TIME in MET:

UTC (+/- error) = TIME + UTCF
MJD (UTC) (+/- error) = MJDREFI  + (TIME + UTCF)/86400.0      (in days)

Since the spacecraft clock is more or less well-behaved on short time scales, UTCF can be made to autonomously update regularly onboard, by adding or subtracting one 20-_second tick on a fixed update interval. As the clock drift rate is measured to change, the value of the interval counter onboard the s/c will be updated by the MOC to compensate. The result is that, in some observations, the UTCF value will gradually change from the start time to the stop time.

Swift users can still get a fairly accurate value of the time by using an additional time header keyword, UTCFINIT, which is the value of UTCF at the start of the file. This keyword is placed into the files at the SDC, using the value of UTCF at the start time of the file. Adding this keyword to the time column in the file will align the start time of the file to within the MOC's tolerance on MET+UTCF=UTC. Thus, to correct times in the file such that the start time is within the MOC's tolerance:

MJD (UTC) (+/- error) = MJDREFI  + (TIME + UTCFINIT)/86400.0      (in days)

Should a user wish to quickly align the start time to an accurate value of TT, he/she will need to keep track of any leap seconds that have occurred since the Swift epoch time (Jan 1, 2001). This is because, if a leap second occurs, UTCF will be adjusted by one second in order to keep TIME+UTCF within the MOC tolerance on UTC. The user would then need to consult a leap second log, and perform the following adjustment:

MJD(TT) = MJDREFI + MJDREFF + (TIME + UTCF + leapseconds)/86400.0

Subsequent times in the file will still drift away from true UTC, but the offset will accumulate from a value near zero, as opposed to an arbitrary time offset. This slight drift should be sufficiently small for users who are interested in a rough correction to the time column in lieu of the full correction available once the more accurate measured clock offset file from the MOC is delivered.