I keep trying to find time to generate a reply to all the points raised
(yet again) during this go-around. New messages keep arriving in the
mean time (a phrase that appears to be under attack). Thanks to
Demetrios Matsakis for keeping us informed. Thanks to Markus Kuhn for
doing a nice job of summarizing why converting to leap hours is
equivalent to not bothering to attempt to keep our clocks tracking
time-of-day at all. Thanks to my friend Steve Allen for continuing to
fight the good fight.
There are several issues to address. If I'm going to actually send
this I won't get beyond the first such. Surely others must find it
remarkable how willing the precision timing community is to pursue the
goal of completely eviscerating the delivery of precision time-of-day
to the public? Are statements like the following really how you want
to sell your product to your funding agencies?
> Given that the average western citizen under 30 years already today
> can barely add up three items in the supermarket without resorting to
> their mobile phones built in calculator today, I think you can
> safely assume that you can do anything to the timescale 100 years from
> now.
Shouldn't we work to educate the public, not use their ignorance of
some issue as justification for degrading service?
Poul-Henning Kamp also wrote:
> As a computer nerd I can fully appreciate the problems and cost of
> converting existing systems to cope with larger UT1/UTC difference,
> but that cost would be peanuts compared to the costs of implementing
> leap-seconds reliably in future systems that would need it.
If you expect astronomers and other supporters of the current Universal
Time system to repeatedly justify continuing to use the definition of
Mean Solar Time that has persisted since 1884, perhaps you could
consider doing us the favor of justifying your own statements. What
exact future systems are we discussing that will both 1) require the
use of Universal Time and 2) not require a definition of Universal Time
that is tied to the rotating Earth? I have yet to hear of a system
that has trouble handling leap seconds that wouldn't have been better
off using TAI instead of UTC. I have yet to hear of a system that has
trouble handling leap seconds that wasn't poorly engineered in its
handling of time standards. Why should the rest of us pay for some
project's bad requirements discovery, bad design and bad
implementation? Imagine that the underlying time standards are,
indeed, changed. Why should we have any greater expectation that the
same suspect engineers wouldn't make a mess of using the new standards?
Attempting to move the entire worldwide civil time system to a
non-Earth based clock is equivalent to attempting to build a clock
designed to run untended for 600 years - in effect, to attempting to
build a millennium clock. The alarm must be designed to ring in 599
years time. The trouble with this is not only that it is a massive
problem in systems engineering. The trouble with this is that the
sociology of time-keeping is working against you. How naive to suppose
that anyone will be paying attention when the alarm rings!
If you want engineers to build systems that correctly incorporate
handling of some phenomenon, you don't require that this phenomenon
only be handled every half millennium. That is a recipe for more lazy
engineering. Leap seconds are a perfectly workable mechanism. Systems
that don't need time-of-day should use TAI. Systems that do need
time-of-day often benefit from the 0.9s approximation to UT1 that UTC
currently provides. Let's stop pretending that *both* atomic time and
time-of-day are not needed. Instead, let's direct our efforts toward
implementing improved systems for conveying both of these fundamental
timescales to users of both precision and civil time. And most
definitely, let's stop these inane and embarrassing closed door
discussions among biased insiders.
It ain't your clock - it's *our* clock.
Rob Seaman
National Optical Astronomy Observatory
Received on Thu Jan 20 2005 - 14:00:12 PST
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT