[LEAPSECS] Cheating means more planning, not less

[Rob Seaman]

Poul-Henning Kamp wrote:


> Rob, you keep making these claims that a lot of 'needs' and  

> 'requirements' are being overlooked.

>

> Why is it that you never offer a single concrete example ?


1) Read the archives.  The astronomers and astronomical software  
engineers here have done the best job of analyzing the concrete  
implications of the ITU proposal for the systems under our care.  Send  
me source code and project documentation and pay me for my time and  
I'll take a whack at vetting your systems.

2) That isn't how system requirements work.  Whether or not anybody  
ever writes down a list, a broad set of interlocking requirements  
exists underlying every system.  For fundamental infrastructure such  
as timekeeping this set is particularly extensive.

3) The burden of proof rests elsewhere:

	http://www.nizkor.org/features/fallacies/burden-of-proof.html


> I think it is a pretty good proposal


The goodness (completeness and consistency) of a proposal is not  
determined by opinion:

	http://www.nizkor.org/features/fallacies/appeal-to-belief.html

This is why peer review subjects assertions to vigorous and rigorous  
challenge.

In my opinion, at a minimum the proposal needs to 1) explain why the  
Torino consensus should be rejected, 2) offer a viable mechanism for  
handling the inevitable intercalary adjustments (of whatever sort),  
and 3) describe in detail how access to UT1 will be provided in the  
absence of DUT1.

That's my opinion.  The goodness of any proposal needs to be  
rigorously established via a process transparent to all.  This is the  
quickest way to reach consensus, that is, to refine opinions on all  
sides.  When the ITU votes it should simply be ratifying consensus.


> and I hope nobody get killed by leap seconds before it takes effect.


Our decisions should not be driven by unsupported fears:

	http://www.nizkor.org/features/fallacies/appeal-to-fear.html

Risks are notoriously hard to characterize.  System engineering  
methodology provides the best tools to do the job.

A good start would be to list concrete examples of risks for projects  
that inappropriately selected UTC when an interval timescale like GPS  
was clearly required.

Rob