[LEAPSECS] Cheating means more planning, not less

[Rob Seaman]

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  
moment.

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  
changed.

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  
systems.


> 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.

Rob