NavList:

   

Reply

The September 2013 ITU News magazine has several articles on UTC and the
future of leap seconds.

https://itunews.itu.int/En/news.aspx?Edition=251

I believe most of the UTC problems described in the articles are really
due to flawed computer implementations of UTC, not UTC itself. We are
told that "stopping all clocks in the world for one second in order to
accommodate a leap second creates an ambiguous hiatus." And there are
"the problems of time-ordering, causality and the ambiguity of time
intervals in the vicinity of a leap second".

In reality, UTC doesn't stop when a leap second occurs, and the interval
(SI seconds) between UTC epochs is not ambiguous. For example, the
motion of a celestial body during a leap second can be calculated
precisely. There should be no discontinuity at entry or exit from the
leap second. To demonstrate, I'll compute the altitude of the Sun at the
center of a leap second, then use a different program to solve the
simulated time sight for UTC.

With the JPL HORIZONS program, create a simulated Sun observation at
2012 June 30 23:59:60.5 UTC from N21.36 W157.96 at sea level. HORIZONS
says refracted altitude of the center = 70.4349° and diameter = 1887.937″.

Now solve for time with my program Lunar3. Use the JPL DE406 or DE422
ephemeris. Position = N21.36 W157.96 at sea level. Temperature 10 C,
altimeter setting 1010 mb. Estimated time = 2012 July 1 00:05 UTC. (To
make the test more realistic, that's 5 minutes in error.) UT1-UTC = +.41
second. Enter altitude of Sun center, 70.4349. Select D.d angle format
and .0001° precision. Check the "solve for time" box and click OK.
Result: 2012 June 30 23:59:60.41 UTC.

That's inside the leap second, as it should be. The error, -.09 s, is
due to refraction differences between the programs. They agree exactly
if you compare unrefracted altitudes at the same time.

It's interesting that the UT1-UTC I gave, +.41 s, was correct for
the estimated time of the sight, but due to the leap second it was
really -.59 when the sight occurred. But that did not prevent an
accurate solution.

I don't mean to imply a time sight is accurate to a tenth of a second.
My point is that leap seconds don't prevent an accurate, unambigous UTC
determination from the motion of a celestial body. But it requires
careful writing of the UTC code.

Regrettably, that was neglected in the design of JPL HORIZONS. It won't
accept 2012 June 30 23:59:60.5 UTC. To get the simulated observation,
what I actually did was convert from UTC to the equivalent time in TT,
2012 July 1 00:01:06.68. A programmer on the JPL staff confirmed my bug
report, and a fix is in work.

This may be a clue to the reason computers still get messed up by leap
seconds, even after 40 years of practice. The UTC implementation didn't
provide for leap seconds, and that part of the program was never tested.

My software is not without sin. If you request a prediction from Tinyac
at the center of a leap second, the time display in the main window says
24:00:00.5 instead of 23:59:60.5. However, the position of the body is
computed correctly. The later Lunar3 program does not have this bug.

Getting back to the ITU news articles, it seems Russia (the Glonass
people, anyway) and the UK want to keep leap seconds. I don't have any
guess on what the final decision will be, but everyone who writes
astronomical software should be ready. If leap seconds go away, even a
printed perpetual almanac will need modification to its instructions.

--

   

Reply