In message <887E1D1A-6B2E-11D9-B9F7-0011242F089A_at_noao.edu>, Rob Seaman writes:
>> 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?
Absolutely! but if you read your classics (relevant keywords: bread
and circus) you would not expect much success.
>
>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.
I think you got the sign of my position wrong here: The cost of
conversion has been used to argue _for_ keeping the leap seconds,
and I say that the cost of _keeping_ the leapseconds will be much
higher in terms of software development and testing.
>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?
The concern I have met from computing system owners is not that
they worry _if_ their system will handle leapseconds, but that they
don't know _how_ it will handle them.
The major problem with leapseconds in computer systems is that they
do not happen often enough to be testable, and for anything networked,
they are untestable unless we set up dedicated "fake time" NTP
servers (like Judah did for y2k), have reliable GPS simulators etc etc.
I saw one test plan for a major safety-of-life system were they
dropped leap second testing because the sheer enormity of doing so,
including fake GPS, DCF77 and NTP timesources where simply not
possible, some of them even illegal.
Their plan: Hope leap-seconds are killed.
Ther fall-back plan: Shut down for an hour citing "emergency
computer problems" and take the political flack afterwards. You
don't even want to know how much money that would cost in lost
throughput if leapseconds didn't happen an hour past midnight here.
No such relief for the asians.
>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.
No it isn't. This is a rubbish argument and you know it.
No matter how reasonable Brahe, Keppler and Newton had been, no
matter how well they had worked out their plan, no matter how much
they had tuned it to their society, we would never have executed
it today according to their design without checking, double checking
and reevaluation of their premises.
And neither are our great^N-grandchildren going to.
We are not designing a new timescale to last 600 years here, we are
designing a timescale for the next century at best, and given the
statistics we should consider ourselves luck if it holds even half
that long before somebody finds something wrong with it.
>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.
It's not the frequency of the phenomena that is the problem, it's
the magnitude.
Nobody puts an entire IT department on call for a one second
event, you just can't justify the expense to top management and
more importantly, with half a years notice you can't budget for it.
But every IT manager would do so for an one hour event. The really
smart ones will plan their three hours of maintenance to coincide
with the event.
>Leap seconds are a perfectly workable mechanism.
For who ? For astronomers ? For computer programmers ? For
risk managers ? For insurance companies ?
Or do you mean because they're so small that most people just ignore
them and since we're in the center/western hemishere we mostly
get away it ? Ask the asians what they think of having that
second in the middle of the day, then come back and call it
"workable" once more.
>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.
I agree, but we have to be realistic and either you are not
or you don't know what you need to be realistic about.
The systems which need UT1(-like) time are staffed by very smart
people.
The systems which need civil time are not. Many of them don't
know that other parts of the globe have different time, fewer
yet know what the difference is.
We need to put the complexity where it can be handled.
Today my civil time is already up to one and a half hour wrong
according to solar time. Scottland is debating making it up to two
and a half hour wrong in order to be in the same zone as most of
EU, and some of the new EU member states are discussing making it
one or two hours wrong in the other direction for the same reason.
On average most of USA must be half an hour off center as well.
If the civil timescale drifts one hour over the next half millenium,
I can guarantee you that none of my decendents would care that the
solar clock they inherited from me is not mounted in the exact same
direction as I had it.
It's actually even worse than that if you look at what people call
"mid-day" in various countries: It's not uncommon for building
workers to eat their "mid-day" at 10:30 here in Denmark, kids in
the school is have it at 11:30.
The numbers we attach to civil time have nothing to do with "noon",
"mid-day" and such mundane concepts.
Nobody today can look at their wristwatch and set their compass
after the sun without doing a considerable amount of correction
already.
Civil time does not have to be linked hard to the sun as long as
it doesn't change too fast.
On the other hand, astronomers and others that need UT1 will be
able to take the global timescale, (TAI, UTC or something else) and
apply a delta they pick up from a scientific entitity and use the
result. Today most of them already have to pick up a +/- 1second
delta anyway, but they are so used to dealing with bigger numbers,
I would trust them to do +/- 10000 seconds and get it right in first
try.
Many of the people who need civil time still have a hard time with
leap years and daylight savings time, and since a lot of these
people inexplicably are tasked to implement and code life critical
systems, you should not task them with an arrythmical phenomena of
negiligble magnitude which they can't test.
I have met engineers writing train and air traffic control software
who didn't even know that leap-seconds existed.
The most scary part is that just some years ago the fad-of-the-year
in program development was called "prototyping" (I maintain that
they simply relabeled "trial and error" :-), and much of that
software were responsible for the Y2K issues that were actually
found. How much of that code do you think copes with leap-seconds ?
Do you think the IT industry is going to magically become better
at handling such minute details when they can't even find a way
to stop spam-mail ?
And when were the last time you heard about a really big computing
system being on budget, on time, working as designed ? Where do
you think leap seconds end up in such a project ?
For every scientist you can come up with who knows what UT1 is, I
can find you ten programmers who will not know what a leap second
is, and they are programmers who program the air traffic control
systems, the heart-rate monitors, the NMR scanners and the mobile
phone you might be at the mercy of during the next leapsecond.
I agree that the leap-hours thing is a slightly phony way to abolish
leap-seconds, but it sounds to me like leap-hours is just the legal
maneuvre we need to enable us to put legislation after the decision
instead of in front of it. As a Dane that sounds smart because
time in Denmark is still not UTC based but based on "mean solar
time" because our parliament has not gotten around to fix it in
the last 46 years.
So my position is clear: Kill leap seconds. Let the people who
need UT1 deal with the complexity. If we need to pretend leap-hours
to keep the politicians out of it I'm all game.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Thu Jan 20 2005 - 15:29:45 PST