Re: trading amplitude for scheduling

From: Rob Seaman <>
Date: Sat, 5 Aug 2006 18:47:29 -0700

John Cowan wrote:

> Rob Seaman scripsit:
>> Third result - even in the absence of lunar braking, leap jumps
>> (or equivalent clock adjustments) would remain necessary.
> Why is that?
> If the SI second were properly tuned to the mean solar day, and the
> secular slowing were eliminated, there would be no need to mess
> about with
> the civil time scale, because the random accelerations and
> decelerations
> would cancel out in the long run. Of course, we'd have to tolerate
> larger
> differences between clock time and terrestrial time, but we'd
> expect that.

Excellent discussion. The answer depends on how much larger the
clock differences are, and on the meaning of the word "tolerate". As
Tom Van Baak said:

> My understanding is that, in addition to astronomical
> effects (lunar/solar tides), no small number of geological
> and climatological phenomena also contribute to the
> instability of the mean solar day. That all the random
> accelerations exactly cancel all the random decelerations
> in any finite time, short- or long-term, is very unlikely.

Which is to say that "proper tuning" may not even have a definition.
It certainly is non-trivial.

Consider the historical trend (from

Detrend the data by removing the 1.7 ms/cy secular effect:

(I read the LOD from the plot every century - should repeat with the
original data, but results should be acceptably accurate. I'm sure
somebody would be happy as a clam to point out any errors I may have
made :-)

There are positive and negative excursions from "normal" that persist
for centuries. For the purpose of civil timekeeping, we don't care
what geophysics causes these excursions, or even whether the rather
evident sinusoid is real or not, but just that the residual ~ +/- 5
ms length-of-day variations exist.

Leap seconds represent the accumulation of these daily residuals:

A very small daily residual becomes +/- 9 minute descrepancy between
TAI and UTC over millennial time periods. So even in the absence of
the secular trend, the natural geophysical irascibility of the planet
is very evident. Leap seconds - both positive and negative, of
course - would be needed to resync the clocks. I count about 2200
over 2500 years (for instance, about 500 leap seconds between the
battle of Hastings in 1066 and the most recent eruption of Fujiyama
in 1707). That amounts to about one leap second per year even in the
absence of the secular lunar effect.

Since this entire range of phase space sits within an hour's extent
from the "mean", the ALHP is really a proposal to completely ignore
the chore of providing time-of-day to the world. Of course, we're
back to the same question we've been debating with our well known
positions all staked out – but the point is – the Moon ain't in it
anymore. The whipping boy for hurrying a decision to emasculate UTC
has been the quadratic lunar term – but large numbers of leap
seconds are seen to be needed every century, whether or not the lunar
term is included.

Of course, on top of this long term trend are superimposed the
decadal and seasonal effects (also from Steve Allen's page):

This +/- 1-2 ms jitter can either magnify or quiet the millennial
effects – for relatively short periods – or equivalently can
accelerate or retard the scheduling of leap seconds. On the other
hand, there is no reason to suppose that the periodicities that have
been revealed since the time of Pericles have completely
characterized our planet's wobbles at the long end of the spectrum.
In particular, The LOD offset plot appears to show a baseline error
of 0.5 or 1.0 ms. Also, the choice of slope for detrending the
historical data was purely a result of a phenomenological fits to the
data in hand. The fact that the lunar estimate, and the estimate
born from the high precision near term data, both differ from the
phenomenological slope could also be taken to suggest that long term
periodicities are lurking in the data, and that even greater
excursions from the mean are not only possible but are inevitable.

Which is all to say that not only does the secular baseline guarantee
that we cannot tune SI seconds to match a mean solar time whose rate
is changing, but the geophysics of the planet lead one to question
what this even means exactly.

What to do? What to do?

Challenge the premise of the question.

Interval time and time-of-day are simply, truly, two entirely
different things. Some pragmatic arrangement is going to have to be
struck between the two. I'd suggest that Babylonian notation be
reserved for time-of-day (UTC) and that interval time (TAI) be
expressed as what it is – a simple count of seconds. But the
details would certainly be open for discussion – if we didn't have
to expend so much effort fending off the Absurd Leap Hour Proposal,
again and again.

But also, we should be investing in the infrastructure needed to
convey both quantities to the vast array of users who need one or the
other at whatever level of precision. Striking a "compromise" that
eviscerates time-of-day for the imagined benefit of some interval
time special interests is not only uncalled for - it doesn't even
begin to address the issues. Time-of-day is solar time and should
always remain such. If there are to be policy changes in the
identification of civil time with mean solar time with Coordinated
Universal Time - these should be driven by issues related to time-of-
day, not force fit to match the pathologically even cadence of atomic

Similarly, if precision time users are having troubles dealing with
leap seconds – we've said it before – they shouldn't select time-
of-day as a time standard! I mean - duh! Why would any sane
engineer who needs a clock regular to one in ten billion specify a
requirement to synchronize their precious system to a clock that only
keeps time precise to one in ten million? Obscuring this simple fact
by trashing UTC for the rest of us is rather – impolite.

Time-of-day is Earth orientation. Atomic time is interval time. One
doesn't have anything to do with the other.

Rob Seaman
Received on Sat Aug 05 2006 - 18:49:05 PDT

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT