Re: [LEAPSECS] two world clocks
Poul-Henning Kamp replies:
> The major problem with leapseconds in computer systems is that they do
> not happen often enough to be testable,
The current UTC standard allows scheduling leap seconds monthly. Is
that frequent enough for you? The question isn't whether a leap second
occurs. The question is how frequently do opportunities for a leap
second occur.
> 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,
And you are asserting that this is a system that would not have better
chosen an unsegmented timescale based on TAI? Or perhaps this system
also has a requirement that no other glitches ever be allowed to occur
within the clocks? What actual requirement did this system have that
equated the preservation of life with tracking UT1? And if there was
such a requirement, are you not providing a strong argument for the
precision timing community to continue to provide an easily accessible
approximation to UT1?
> Their plan: Hope leap-seconds are killed.
Remind me not to rely on their system for my own safety. So their
system requires a clock synced to civil time to keep people alive.
Does it also suspend a 500 kilo weight over the operator's console with
the rope connected to an alarm clock set to go off at the end of June
and December? We can pass anecdotes back-and-forth all day long. Is
the ITU or some other organization pushing this change actually
compiling useful data on all these anecdotes?
> 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.
Yes. I do want to know. Or rather, I want to have confidence that the
bureaucrats pushing this silly initiative are actually investing in the
world-wide inventory of time users that is warranted by a scheme to
change every clock on the planet.
> 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.
Sounds like a great business opportunity. There are large numbers of
much more obscure standards that programmers manage to get right. What
reliable evidence do we have that programmers are screwing up UTC
left-and-right? Couldn't we just invest in improving the NTP handling
of leap seconds and in implementing new time handling facilities
*before* we go about deprecating leap seconds?
> 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.
These are either periodic effects or constant offsets. Leap seconds
are due to a secular effect. That secular effect won't go away just
because some folks wish very hard.
> The numbers we attach to civil time have nothing to do with "noon",
> "mid-day" and such mundane concepts.
They actually have very precise, closed form approximations to those
concepts. Many of us like the equation of time. Why throw it out?
> Civil time does not have to be linked hard to the sun as long as it
> doesn't change too fast.
Civil time is used for a myriad of purposes. One might think that the
precision timing community would be an excellent choice of folks to
enumerate these various purposes. This has not been demonstrated over
the past five years. Rather we've seen one lame and lazy attempt after
another to avoid doing the detailed leg work needed before changing
such a fundamental standard.
> 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.
As you imply, a vast amount of astronomical software and systems would
indeed need to be modified quickly and reliably simply to preserve the
current functioning of our systems.
> Today most of them already have to pick up a +/- 1second delta anyway,
No. I would guess that most of them manage to work within the +/- 0.9s
approximation of UTC to UT1. Entirely new code and systems would need
to be fielded. And yet somehow the precision timing community doesn't
make it a priority to explore these new systems. Could it be that this
is simply an attempt to dump the tracking of Universal Time back in the
laps of the original timekeepers, the astronomers?
> 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.
And you are asserting that the proper solution is not training and a
coordinated development of precisely the global time distribution
systems and APIs that are needed, but rather to ignore the problem
entirely? Inexplicable indeed.
> I agree that the leap-hours thing is a slightly phony way to abolish
> leap-seconds,
New topic. One of the few points of consensus coming out of Torino was
that any new civil timescale to be defined without leap seconds would
be given a new name distinct from Universal Time (of whatever flavor).
Universal Time was to be reserved for timescales synchronized to the
rotation of the Earth. One might wonder at the reluctance of
proponents to follow through on this easily comprehended consensus.
Rob Seaman
National Optical Astronomy Observatory
Received on Thu Jan 20 2005 - 23:44:49 PST
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT