Re: [LEAPSECS] Precise time over time
Poul-Henning Kamp says:
> The fact is that embedded systems these days are not stand alone,
> but rather well connected and coordinated.
This doesn't sound like a good argument for debasing the underlying
model of time. As Galileo said (or maybe he didn't, but I'll bet he
thought it): "Eppur si muove" - "It still moves!" Since Galileo's
day we have settled the question - the Earth does still move and that
has significant implications. Embedded systems work better when they
are embedded in the real world.
> If you want a really disturbing experience, visit a modern
> robotical slaughterhouse, and while you are there, observe and
> think about what a one second difference could do the the tightly
> coordinated choreography of the robots.
Yes, please Daddy! I want a really disturbing experience!
I suspect this is exactly the scenario that the ITU committee members
have been looking for to sell their proposal to the public. "Just
imagine, little Sally, that the Earth is a recently deceased steer
hanging upside-down from a meat-hook - and C3PO and R2D2 are wielding
flensing knifes the length of your little brother Billy. You
wouldn't want your little robot friends to slice off each other's
appendages when they're aiming to carve out the brisket - the oil
reserves in the Middle East, that is? Now would you? Repeat after
me, children: Leap Seconds are baaddd! Atomic Time - like Atomic
Energy - is good!"
Moving on...
> The problem with leap seconds is when the systems are in touch with
> each other, have synchronized clocks and know it, and then suddenly
> some of the systems insert an extra second, and some of them don't...
Robustness is a key requirement for interoperable systems. A system
that cannot tolerate the slightest deviation in behavior from another
system is not robust. And besides - systems with critical
requirements such as you describe (assuming any exist - requirements
or systems) can use TAI instead of UTC. This has always been the
case. This will always be the case. What might not be the case in
the future is that systems (and civilians) with requirements based on
Solar time would continue to have access to appropriate time signals.
Why should the existence of systems requiring resource A (whatever A
is) be taken as an argument that other systems be denied access to
resource B?
So now we know that robotical slaughterhouses require atomic clocks.
Who would have thunk it! What does that possibly have to say about
civil time standards?
> And you can say all you will about bad impmentations and people
> deserving what they get etc, but what you and others feel in that
> respect does not change the economics of the situation.
And repeating this incessantly doesn't remove the need to
characterize the cost of BOTH eliminating as well as retaining leap
seconds. I'm fascinated that there isn't the slightest recognition
that systems - interoperable systems - currently in the field might
well have inherent dependencies on the reality of Earth orientation.
After all, vast economic forces are dependent on the realities of
living on a planet with a tilted axis, orbiting a far from quiescent
Sun. Like what, you say? Like farming and shipping and tourism and
anything else that is climate or weather dependent. Are only the
annual shenanigans of the Sun of economic importance? Somehow the
daily Solar behavior is worth exactly zero, but 365 times zero is
billions (or trillions, more likely) of dollars?
The Sun matters. Wishing it were not so doesn't change the fact.
Simply assuming that no safety critical system anywhere on the planet
could possibly, even in our wildest Spielbergian imaginations, ever
depend on the long established notion of Mean Solar Time that
permeates our civilization - simply assuming this does not remove the
economic, legal and moral imperatives to investigate these
possibilities before unilaterally changing a 120 year-old
international standard.
Duck and cover!
Rob Seaman
National Optical Astronomy Observatory
Received on Wed Aug 10 2005 - 17:18:18 PDT
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT