[LEAPSECS] Reliability

[Rob Seaman]

Adi Stav wrote:


> On Fri, Jan 02, 2009 at 08:29:21PM -0700, Rob Seaman wrote:

>>

>> Civil time is solar time.  The rate is the issue, not local offsets.

>> Let's move past the fantasy that the ITU can redefine timescales  

>> willy-

>> nilly to serve the requirements of a civilization of mole people, and

>> rather address the actual requirements of our own civilization.

>

> I'm trying to understand this position. I have a question.


I appreciate both the question and the polite way it was asked :-)


> If I understand correctly, you require that civil time is kept  

> synchronized with mean solar time, and you also agree that UTC,  

> which is synchronized to mean solar time with DUT of less than one  

> second, complies with this requirement.


I am the one expressing these opinions, yes, but this is a broadly  
derived requirement.  UTC currently satisfies it.  The ITU proposal  
would not.


> Then, what is the maximum DUT a time standard can have and still  

> comply with this requirement? How is this maximum arrived at? Or, if  

> compliance with the requirement cannot be decided in such terms,  

> then in what terms can it be decided?


Well stated.  Requirements derive from use cases.  Use cases pertain  
to all the stakeholders.  In the case of civil timekeeping, the  
stakeholders are all the people on Earth.  Clearly everybody can't  
participate in making the decision, but a little humility in the ITU's  
decision-making process would be appreciated.

I remain flabbergasted that of all the postings I've made to this list  
over the years - postings like the recent one that speculated 5  
billion years into the future - that of all these, the ones to  
generate full-throated outrage as a result are when I humbly suggest  
that normal system engineering protocols be followed.

Which is to say that I can speculate on an acceptable maximum value  
for DUT1, but that misses the point.

I could say, for example, that 4 seconds wouldn't make me gag too  
badly (even though this corresponds to a full arc-minute at the  
equator).  If we feed this into some Bayesian simulation using  
historical values from Bulletin A to predict the baseline truth of  
Bulletin B, this seems likely to give us a decade or more lead time on  
announcing a leap second schedule.

But speculating on a solution and then inverting the process to define  
the problem is not a very clever sort of engineering.  Rather,  
characterize the problem first.  With a clear set of requirements in  
hand, it might well be - it almost surely will be - that we would  
identify a consensus solution that satisfies all stakeholders much,  
much better.

A civil timescale is not like a technical timescale.  We are  
attempting to satisfy many different purposes at the same time.  The  
"easiest way out" is very likely to be one of the worst choices.

My suggestion for the skeleton of a process is:

1) Perform a more careful simulation as in the Arias, et. al. paper:

	http://www.ucolick.org/~sla/leapsecs/torino/arias_3.pdf

Vary the parameters, characterize how well predictive scheduling of  
leap seconds can actually do.

2) Reach an interim consensus on a reasonable trade-off of the  
parameters.

3) Implement this under the current standard (or make a modest, non- 
controversial change to the standard as required).

Simultaneously:

4) Seek funding for a proper long term study of the requirements of  
civil timekeeping.  Surely some combination of national and  
international funding would be available to do the job right.

5) I have to believe that #4 could have resulted in findings in less  
than the nine years the current lack of a coherent process has burned  
through.

6) With actual requirements in hand, perform a broad trade-off of the  
very distinct options that have been mentioned here over the years.   
It is likely that a coherent set of requirements will suggest several  
options we have never even considered.

7) Further debates will then be informed by, and strengthened by, the  
requirements and resulting trade-off study, but also by very standard  
methods of system engineering such as risk analyses, sensitivity  
analyses, etc and so forth.

8) This isn't only the best way to do the job, it is the quickest way  
to finish it.

Rob