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
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
