[LEAPSECS] Civil timekeeping before 1 January 1972

[Paul Hirose]

On 2015-03-06 18:02, Harlan Stenn wrote:
> When we get a bit more down the road with NTF's General Timestamp API,
> I'd appreciate your taking a look at what we're doing and helping out in
> any way you are up for.  One of the issues that will need more attention
> is pre-1972 stuff.

The rubber time era can be tricky. I just finished a major rewrite of my 
UTC implementation in the C# language. The goal was improved accuracy 
before 1972. Although the old version passed all my tests at 1 
microsecond accuracy, it began failing when I tightened the error 
tolerance to 1 nanosecond.

A couple adjacent lines from the USNO table show the problem:

1966 JAN  1 =JD 2439126.5  TAI-UTC=   4.3131700 S + (MJD - 39126.) X 
0.002592 S
1968 FEB  1 =JD 2439887.5  TAI-UTC=   4.2131700 S + (MJD - 39126.) X 
0.002592 S

The last instant of the first line is 1968 Jan 31 23:59:59.9, since a 
step adjustment shortens the last minute. The first instant of the 
second line is 1968 Feb 1 00:00:00. These UTC epochs are equivalent and 
should convert to the same TAI.

But if you do the math, the second line yields a TAI 3 ns after the 
first line. In other words, there's a 3 ns slice of TAI with no UTC 
equivalent.

The reason is the rate correction, which in both lines is (MJD - 39126.) 
* 0.002592 s, where MJD is UTC in the form of a modified Julian date. In 
the first line the expression in parentheses yields a true amount of 
rubber time since the base epoch MJD 39126.

In the second line that's not the case. Due to the step adjustment, 
subtracting 39126 from UTC yields a value .1 s greater than the actual 
elapsed time. That's about 1.16e-6 days. Multiply by the .002592 s/day 
that TAI gains on UTC, and you get the 3 ns discrepancy.

I don't believe 3 ns is significant for any time stamp from that era. 
Anyway, the number of decimal places in the USNO table (4.3131700 etc.) 
implies accuracy to only 100 ns. However, my implementation is capable 
of time scale conversions accurate to 1 ns with a comfortable margin. I 
wanted to realize that potential.

The solution was to leave the step adjustments as-is and make subtle 
adjustments to the rates. This was more difficult than I expected. The 
user is responsible for loading the USNO text file at run time, so none 
of the work can be done in advance. Moreover, my implementation is 
designed to support experimental modifications to the UTC table, even 
wild stuff like re-introduction of rate offsets. Thus nothing can be 
assumed.

My solution is to make one pass through the USNO file to construct a 
preliminary table. Then a pass through the table puts in the step 
adjustments, which are implied by the USNO data but not listed. A final 
pass makes the rate adjustments. At the user's option the last can be 
omitted for a literal version of the USNO table. It was a lot a trouble 
to get there, but I'm now accurate to a nanosecond.

You probably won't get that crazy, but testing for discontinuity as you 
cross from one table entry to the next is still a must. That's 
especially true pre-72, where it's easy to make a mistake. One of my 
tests is to compute TAI for two epochs one microsecond either side of 
the boundary between table entries. For instance, for the lines I 
included above, I'd begin with UTC epochs 1968 Jan 31 23:59:59.9 - 1 us, 
and Feb 1 00:00:00 + 1 us. Convert both UTCs to TAI, and verify the TAIs 
differ by 2 us.

(Formally, the correct value isn't exactly 2 us due to the rate 
difference between TAI and UTC. But that's insignificant over such a 
short span.)

Also, you should convert both TAIs back to UTC and verify accurate round 
trips.

It might seem that you could begin with UTC epochs Jan 31 23:59:59.9 and 
Feb 1 00:00:00, convert to TAI, and verify zero difference (within a 
given tolerance). The problem is that both TAIs can map to the same 
table entry when you round trip them to UTC, and so the other entry 
doesn't get tested as expected. (In my implementation each entry does 
both UTC -> TAI and the reverse.)

Of course an accurate round trip UTC -> TAI -> UTC doesn't prove TAI is 
correct. You have to check that separately.

I don't take any position on whether or not pre-72 is really UTC. 
However, both IERS and USNO seem to recognize it as such, so I assume 
users of my software may expect that as well.

Similar decisions will face programmers if leap seconds are discontinued 
but the time scale keeps the same name. If you subsequently release a 
software package that converts between UTC and other scales, you'll have 
to decide whether or not to support the leap second era.