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.
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
