[LEAPSECS] Cheating means more planning, not less

Rob Seaman seaman at noao.edu
Mon Dec 29 11:05:59 EST 2008

My apologies for the long reply. The personal attacks reached a
tipping point. Others should feel free to skip this (as I'm sure they
do all my messages :-)

Poul-Henning Kamp wrote:

> Rob Seaman writes:


>> Just one comment. The requirements for "timing applications" (of

>> whatever precision) are distinct from the requirements for civil

>> clock applications.


> You seem to think "civil clock applications" is little old ladies

> walking to church once a week.

My parenthetical remark about precision seems to have been
insufficient disclaimer. Apologies for yet another Strother Martin

That is one use case, yes.

But the real point I'm failing to communicate is simply the
distinction between clocks and timers. Since it is a truism that
every thread on leapsecs has been discussed previously, you can find
some insightful comments from folks like Steve Allen in the archives
on this topic. The two different types of timekeepers may previously
have been referred to as clocks and chronometers.

A timer keeps interval time - highly precise, but perhaps only
accurate in a relative sense.

A clock keeps Earth orientation time (or other fundamental reference)
- accurate in an absolute sense, but not necessarily very precise.

The point is system engineering again. The requirements for an
interval timer are simply distinct from the requirements for a clock.
They may overlap, they may not. One or the other set of requirements
may be more important for a particular application.

As all within reach of my keyboard surely know, I believe civil
timekeeping to be fundamentally dependent on requirements pertaining
to Earth orientation. I am well aware that others here (where "here"
is a place to be understood metaphorically, see Steven Pinker),
believe that interval timekeeping requirements are more critical, at
least since the invention of the computer.

In the statement above I was trying to separate the two in a
noncontroversial way. Apparently I failed. Let's see. Is the
distinction clearer if I say that an egg timer and the "clock drive"
of a telescope have different requirements?

Anyway, to resolve the requirements for such divergent applications, I
have been recommending that well-known system engineering techniques
be followed. Techniques that are eminently applicable to situations
in which diverse entrenched positions have been taken. On the other
hand, Warner, for instance, has simply suggested that one or another
party steel themselves to lose. If we assume somebody has to lose,
then perhaps that will become a self-fulfilling prophesy. I don't
assume anybody has to lose.

In any event, UTC has always provided access to interval time much
more precisely (milliseconds or better via radio signals, microseconds
or better via NTP) than to Earth orientation time (0.9s uncorrected,
0.1s corrected). At any point have I suggested that interval time
should be degraded?

Rather, the ITU is unilaterally proposing to dramatically degrade
access to the Earth orientation related features of clocks worldwide.
As I believe you should know by now, I don't appreciate this and have
been trying to argue against it. For some reason, this appears to
upset you. For some reason, the subject of the discussion keeps being

Leap seconds are simply a facet of an engineering solution. A
different solution could involve other engineering choices. The ITU
is not pursuing a different solution, they have been relentlessly
pursuing the destruction of the current solution. I believe they have
taken this path because they have skipped important steps of standard
system engineering methodology. Central to this is a rush to
judgement, the familiar human quality of failing to explore the
problem space sufficiently before seizing on a specific solution.
Perhaps there is an evolutionary argument for this human behavior -
something about fleeing lions on the savannah. How do you say "look
before you leap" in Danish?

Each problem has many solutions. If we didn't have to keep fending
off the ITU's "deliberations", we could flesh out some high priority
use cases (on all sides), utilize these to discover the underlying
requirements shared by those use cases, and dispassionately consider
alternative solutions that have the likelihood of making everybody
happier with the ultimate consensus.

This is not only a better decision pathway, it is most assuredly a
pathway that will be traversed much quicker than the nine years that
the ITU has squandered.

> A modern passengerplane moves approximately 300 meters per second.

> Are you willing to to accept a +/- 300 meter tolerance on the radar

> track during final approach in Cat3 conditions, if you are on the

> plane ?


> How much havoc do you think a one second difference makes in a

> modern robotic car-production facility ? Have you ever wondered why

> the car industry is so interested in IEEE-1588 ?

These are excellent use cases. Whether the assembly line of an
automated factory has a strong requirement for synchronization with
Earth orientation is unclear. I suspect we would both deem this not
to be the case. I would infer that they ought to consider relying on
something other than UTC. (Say! GPS is quite easily available!) The
implicit argument is often made on this list, rather, that UTC should
be modified to lose its unique features. Square pegs and round holes
and all that.

In the case of the airplane, a better appeal to fear (http://www.nizkor.org/features/fallacies/appeal-to-fear.html
) would feature having my child alone on the plane and needing
emergency medical treatment, during that hurricane when the insidious
leap second sneaks up on the pilot.

Yes, there are risks associated with every technological solution.
System engineering provides the best tools for properly characterizing
and mitigating these. Since day one, the ITU has assumed that the
wide world over there is not a single risk associated with systems
expecting Earth orientation and receiving nadda. Astronomers have
pointed out several risks in our own systems. So, of course, as a
result we are accused of not characterizing them in other people's

> Having to classify applications into "timing" and "civil" in the

> first place is what brought us here.

Someday perhaps we will learn to forgive our ancestors for having the
audacity to be born on a planet with a large moon. See "Rare Earth:
Why complex life is uncommon in the universe", by Peter Ward and
Donald Brownlee (http://www.worldcat.org/oclc/57026195&ht=edition) for
an argument regarding why it might be inevitable that all intelligent
life (multicellular, for that matter) arises on planets with large
moons. The need for leap seconds (or their equivalent) may therefore
be built-in.

I often include modifiers like "or their equivalent". For some
reason, this is not sufficient to impress the very real fact that I'm
willing to entertain alternatives. My apologies for failing to find
the right language yet again.

Simply abandoning leap seconds is goofy. There are many non-goofy
options. For instance, you and I have agreed in principle in the past
on finding it acceptable to lengthen the leap second scheduling
algorithm in some fashion. What exactly is the current state of the
art for predicting Earth orientation? It is a shame that there are no
lurkers here who could answer that question.

> A lot of people didn't know that their applications were "timing" so

> they didn't add code for the leap-second-polka.

Sounds like you've discovered a significant educational requirement.

>> The key issue is the stability of the civil timescale, not its

>> precision. However, degrading the precision by 5 orders of

>> magnitude in one gulp seems rather...excessive.

[Ad Hominem attack excised: http://www.nizkor.org/features/fallacies/ad-hominem.html

> The earth is not going to jump 15 degrees of rotation on jan 2nd

> 2018, so any talk about "degrading precision by 5 orders of

> magnitude" is disinginuous and deliberately misleading.

This is another one of the 42 fallacies from http://www.nizkor.org/features/fallacies
, but I'm tired of paging through them to find it.

The issue here is the meaning of the word precision. As I said in
some other recent message, "precision" isn't a simple concept in
timekeeping. Others here know much more about this than I do.

Whatever precision means, however, a reasonable interpretation of my
secondary point in the informal argument above would be that if the
controls are removed from some system that will inevitably permit
error terms to grow to that magnitude, that it is reasonable to refer
to it as such a magnitude.

For example, pick a bound much larger than the current 0.1s (or 0.9s),
say 100s. It should take us a century or so to reach that. And yet -
the ITU proposal could not make the claim that the new-and-degraded
UTC will remain bounded at 100s, which is 2 or 3 (depending on how
you're counting) orders of magnitude worse "precision" than is
currently true.

> As has been well documented, it will take several hundred years

> before the difference approaches an hour.

Yes, but the system isn't bounded. One could infer that it is
"disingenuous and deliberately misleading" of the ITU to pursue an
agenda that is quite unsupportable over the long term.

> Second, the ITU proposal decentralizes the time-of-day vs. solar

> position tolerance to national issue.

You assert this. I disagree. It is more productive to haggle over
requirements describing the problem space in this area, than it is
over whether a single proposed solution has such a feature. Work
characterizing the problem space will inform all candidate solutions
that are later entertained. Work to characterize a single proposed
solution only helps in the evaluation of that solution, but also may
fail to converge simply because the diverse stakeholders never took
the time to find common ground for describing the problem.

> I think is very proper, considering the very different policies

> adopted with respect to timezones (EU vs China for instance) and

> different durations of sunrise/sunset (Van Mayen vs. Congo for

> instance).

Again, these are good use cases to fold into the process.

>> Rather, the nine years spent ankle-biting at the ponderous

>> machinations of the ITU could have been better spent actually

>> discovering a full set of requirements for civil timekeeping.


> So Rob, why didn't you ?

Again, read the archives. I assayed several attempts. You have
frequently been a noise generator (http://www.naturestapestry.com/whitenoise2.html
) when I have done so.

As with most things, it is also a question of funding. Long since,
some working group associated with the ITU could have sought funding
for an initial design phase. It is commonplace that projects are
funded early simply to write a proposal. Sometimes this passes
through several iterations.

> Ankle-biting is the best description for your disinformation

> campaign I have seen yet.

And yet you have spent this entire message sniping at some other
member of the mailing list when you could simply ignore that
contributor's messages. One might infer (rightly or wrongly) that if
the arguments I make here were so easy to dismiss, you would have
dismissed them (and me) long ago.

I have no authority and presumably little influence of any sort over
the ITU. I argue my position as best I see it with the hope that some
of it might stick. It concerns me that you think otherwise, but I
choose to keep trying.

Once more from the top:

There are two kinds of time, interval and Earth orientation.
The ITU proposal addresses only one.


More information about the LEAPSECS mailing list