Implementent non integer UTC - TAI for dates before 1972-01-01

[miccoli]

Recently I was comparing earth rotation from

• the EOP C01 series which reports UT1 - TAI from 1956
• the EOP C04 series which reports UT1 - UTC from 1962.

For doing so I needed the UTC - TAI offset before 1972. Unfortunately in skyfield UTC - TAI = 32.184s - (ΔT + DUT1) is only implemented after 1972 and assumes only integer values. This is discussed in #679.

I would like to open a PR for solving this issue, but before starting the implementation I would like to summarize the options available to understand if there is consensus on how to proceed. Of course @brandon-rhodes has the last word, but I'm myself a little bit confused, so before opening the PR I would like to hear some opinons.

Sources for the UTC - TAI offset are

• https://maia.usno.navy.mil/ser7/tai-utc.dat which reports data from 1961-01-01 (JD 2437300.5) to the last leap second
• SOFA subroutine iauDAT which uses the same data points as the above source plus an extra data point which backdates the UTC scale to 1960-01-01.
• Table 2.58.1, pag. 86 of Seidelmann, P. K. (Ed.). (1992). Explanatory Supplement to the Astronomical Almanac. This reference clearly states “UTC began 1960-01-01” and is the source for the extra data point in SOFA. Moreover the origin of UTC is linked to the WWV radio signal, and the table of offsets goes back to 1956.

Open questions.

1. When do we conventionally start the UTC timescale?

   1. 1972 (current skyfield behaviour)
   2. 1961 (USNO table)
   3. 1960 (SOFA and Explanatory Supplement)
   4. 1958 the TAI epoch (TAI = 0 at 1958-01-01 0.0 UT2)
   5. 1956 the inception of atomic time

2. What do we do when a user requests a date before the conventional start of UTC?

   1. return the offset at the conventional start of UTC (current skyfield behaviour)
   2. return NaN
   3. raise an error
   4. raise a warning and return 0 (SOFA)

Astropy uses the ERFA version of SOFA, so it's behaviour is 1.iii and 2.iv.

For visual comparison diagrams with the EOP CO1 UTI-TAI vs various implementations of UTC-TAI are given below.

This is 1.i–2.i (current Skyfield)

And this is 1.iii–2.iv (astropy and SOFA)

My current preference would be for 1.iii or 1.iv and 2.iv.

Choosing 1958 as the conventional start date for the UTC scale is historically innacurate (there was no UTC back in 1958) but has the clear advantage that there is no discontinuity if 2.i or 2.iv is chosen for out of domain dates. In this case the 1958-1960 UTC time would be defined as the radio signals broadcasted by WWV in the US.

[brandon-rhodes]

Thanks for providing these details and the graph, @miccoli!

I am currently preparing a talk that I'm due to give at PyTexas this coming Saturday, and so, alas, won't be able to write up a detailed response until afterwards. (And maybe not until another conference, PyCon, is over in late April.) But my guess is that Skyfield should stick with its default, because an integral second offset is easy to implement given some clever NumPy maneuvers:

https://github.com/skyfielders/python-skyfield/blob/master/skyfield/timelib.py#L677

I'm not sure the same numeric technique will work with the not-whole-second jumps that the timescale made back before UTC? In which case, opting for pre-UTC atomic-based time scales would slow down Skyfield. So: I think that choosing pre-UTC atomic time should be fully supported, but should be opt-in, where when folks create their Timescale object they specify the behavior they want.

In which case—maybe instead of having to choose between options like 1.iii and 1.iv, they could just tell the Timescale what behavior they want!

[miccoli]

@brandon, no hurry, reply when you have time.

Let me just point out that pre-1972 is not pre-UTC. We can discuss if it started 1960, 1961, or even 1963, but you will find plenty of references in the 60' to coordinated universal time, spelled out as UTC.

E.g. in this short but interesting article: Sadler, D. H. (1968). ‘The Metrication of Navigation.’ The Journal of Navigation, 21(2), 236–237 you read:

U.T.C. is actually based on Atomic Clock Time, obtained by the integration of the reciprocal of the frequency of the caesium resonance transition that now defines the second in the Systeme International des Unites; but it is at present adjusted, under international control, by both offsets of frequency and small discontinuities, so that it does not deviate from U.T.2 by more than about ± 100 milliseconds.

But I agree that pragmatically each user should be able to choose the UTC semantics that better suits its use cases.