On Aug 12, 2005, at 12:10 AM, Poul-Henning Kamp wrote:
> If it gets put officially on their table by an ITU-R member state,
> their rules does not allow them to ignore it.
I suspect the reality is rather different. The real game rarely
focuses on the rules.
> Worst case it will take a few thousand CHF to get somebody accredited
> as a WP sector member in order to get it put in their inbox.
Thanks for volunteering to fund this!
> Absolutely. No disagreement there, but I doubt the predictive
> capability will be able to gain much performance from being allowed
> to schedule a leapsecond on 2049-11-30 instead of 2049-12-31 at
> this point in time. That of course is not the same as saying that
> we can't in the future, so I'm open for it.
Amplitude of jumps and scheduling frequency are roughly inversely
related until you hit the predictive horizon, whatever that is.
(Certainly shorter than 50 years now, and perhaps shorter than 50
years as a theoretical limit.) See the analogy to Nyquist sampling
in
http://iraf.noao.edu/~seaman/leap.
If we were to move to a leap minute scheme, a ten year sampling
frequency would likely suffice for the next few hundred years. Look
at
http://www.ucolick.org/~sla/leapsecs/dutc.html#ancient.png. The
area under the LOD curve is the accumulated total of leap jumps,
whether these are divvied into seconds, minutes or hours. You can
see the oft-quoted quadratic nature of the effect in the acceleration
of the jumps required as you move away from the 1820 pivot point into
either the past or the future. The most recent half hour
accumulation provides a reasonably smoothed phenomenological estimate
to work with. It took (erring on the conservative side) six
centuries to accumulate that half hour delta. That is 20 years per
minute lag. By the reasoning in my proposal, that would require the
freedom to schedule every 10 years to ensure that both the amplitude
and schedule frequency remain within bounds.
Note that a leap minute would not occur every decade - rather the
opportunity to schedule one would occur. And note that this is an
orthogonal question to how far in advance the need for leap minutes
could be predicted (and thus scheduled). And both of these are
orthogonal to the actual scheduling policy that would be
implemented. I would (and have) argued that we should be minimizing
DUT1. With leap minute scheduling, DUT1 could be kept to a tight
envelope around +/- 30s. How tight is a question for debate. Unless
we're completely wrong about the effect of lunar tides to slow the
Earth's rotation, no negative leap minutes should ever be needed.
This would be something of a moot point since I argue later that all
leap minute adjustments would naturally be manually performed.
> If we go to 50 years horizon, then the permitted size will have to
> go. The size will be whatever the predictive capability results
> in. I would think that we can keep it less than 5 seconds at this
> point, and probably better than 1 second 20 years down the road.
>
> If we put a cap on it, we have two conflicting requirements and we
> gain nothing but trouble.
As I just explained, the requirements are like any other system and
its requirements. They don't conflict, rather they have to be
balanced one against the other.
I think there is real value in simplifying the concept of whatever
civil time (and calendar) policies are ever instituted. An open-
ended amplitude with odd and varying jump sizes is more than
unpalatable - it simply would never be adopted. The concept of a
leap second is significantly different than the concept of three leap
seconds inserted at the same time. A leap minute is not as elegant
as a leap second, but it is far preferable to a random duration leap
jump.
> But I think the predictive capability would already allow us to
> hold it well inside a minute with a 50 second horizon and leapseconds.
Again, look at Steve Allen's LOD plots - the historical behavior
shows excursions of several milliseconds - in LOD, not the
accumulated delta corresponding to leap seconds/minutes/hours. There
is a general trend that is barely discernible over recent centuries.
The length of the solar day a century ago was longer than today
(although both were greater than the 1820 pivot). It should be
interesting to see how deep the current trough goes. Look at the
deep trough and high mountain before and after 1900.
> I would even think that there would be time to change TF460 in a
> structured way before we would hit the 1 minute, should something
> unexpected but non-catastrophic happen to Earth.
What both the champions of Solar Time and of Atomic Time agree on is
that something interesting and often unexpected is always happening
to the Earth. What we disagree about are the implications. Folks
like me take this as an argument for improving our basis of civil
time on Solar Time. Others see this as a reason to forget the whole
thing and pretend the Sun doesn't exist. The underlying reality is
simply that human civilization requires BOTH Solar Time and Atomic
Time as well as a whole bunch of "dynamical" time scales. UTC (and
variants that we are entertaining for the purpose of this discussion)
have the advantage of providing access to both Solar and Atomic time
in one package.
> If the horizon is long enough, we can make the operating system
> do the right thing and then it will take a truly moronic programmer
> to screw it up, as opposed to now where it takes a truly dedicated
> programmer to get it right.
Interesting thesis. Is that what was observed with Y2K? We knew the
millennium was coming no later than the time of the previous millennium.
Rather, if the horizon is too long, even educated and motivated and
dedicated technical personnel will have a hard time convincing their
management to commit any resources for a theoretical fix to a problem
that as you argue might be guaranteed not to occur during the
lifetime of a project - perhaps even be "guaranteed" not to occur
during the lifetime of any deployed systems that later form a legacy
halo around the project. The trouble with guarantees is that they
are often "lifetime" guarantees - and the pertinent lifetime is the
the professional lifetime of the manager involved. The guilty
parties will be long gone by the time that folks realize that the 50
years is fast approaching.
Surely the point of leap hours (if there could be said to be a point)
and of leap minutes is that if an event is rare enough it can be
treated as one of the long list of rare interruptions that are
required to be handled with manual recovery procedures. Even nuclear
power plants have contingencies for earthquakes, floods, tornados,
hurricanes, volcanic eruptions and other acts of God. Basically, a
leap hour or minute is designed to be treated like an act of God. I
find this an unfortunate choice - like I said, I would prefer a
monthly scheduling cadence - but if I were managing a project (say,
49 years hence) that faced a looming leap minute or hour the only
proper response would be to activate a disaster prevention (and
contingent recovery) tiger team.
Of course, most "projects" (meaning civilians and neglected legacy
systems) would simply ignore the leap hour and have to clean up the
mess afterwards. For some systems, this would amount to simply a
glitch. To other it might be a Y2K-like disaster of biblical
proportions. We missed the bullet with Y2K because the approaching
millennium was hard to miss. We won't miss the bullet with leap
hours precisely because we will have turned civil time into something
to ignore, rather than something to understand.
> I disagree. The problem with the current short horizon is that
> it involves the users in the event because they have to update
> software to get it right.
>
> If the horizon allows the knowledge to be safely put into the
> operating system, knowing that it will be correct for the lifetime
> of the system then only a few people for each operating system need
> to be involved and get it right.
The horizon is not short enough yet. The leverage needed to make
these operating system changes (assuming anything equivalent to an
operating system is involved) is precisely the threat dangling over
their heads of a monthly leap second. As you imply, it isn't enough
to fix systems once - new systems are being built every day. Rather
adherence to proper civil time standards has to be elevated to the
top of the requirements list for all new systems such that new
solutions are designed, implemented, commissioned and tested all the
time. This is a recipe for a booming new industry, not an invitation
to throw your hands up in disgust.
> Because the people behind the current proposal is driven by economics,
> not science.
Would you please stop waving the word "economics" like a magic wand?
Economics must be responsive to real world issues. Science is simply
the identification and understanding of precisely those issues. I
guarantee that no real economist would think anything that has been
written or said about leap seconds over the past five years (or 25
years) merits consideration as any sort of economic analysis. There
is a cost to leap seconds. There is a cost to not having leap
seconds. An economic analysis of any pertinence to our discussions
would explicitly investigate and balance the costs on both side.
The identities - let alone the motivations - of the "people behind
the current proposal" are unknown. It certainly isn't principally
economics or they would have trotted out reams of documents as
justification. The business community is good at presenting a
business case for changing policies more to their liking.
> If we want to stand a chance in this fight, we have to come up with
> a competing propoposal with competitive economy and better science.
>
> And we have to do it in the next few months.
You are implying I believe that we throw together some proposal for
consideration at the November ITU meeting? Anything produced on such
a time scale - as with the current proposal - would hardly deserve
consideration. It seems extremely unlikely that it could be
navigated through the bureaucracy for a hearing at that meeting.
Rather, we should be focusing on laying the groundwork for a future
proposal. Part of that groundwork is seeking the rejection of the
current abortion of a proposal. It is unacceptable - it should
simply remain unaccepted.
> As I said, 50 years seems right, and it does so because there is
> no currently running computer that has worked for 50 years.
>
> Most electronics is considered unreliable for safety of life after
> 10-20 years and in general after about 30-40 years.
>
> 20 years might be livable because while there are computers which have
> been running for more than 20 years, having to update a table for
> those
> few systems might be livaable, but it does get us into the area where
> long lived embedded systems need updates.
>
> I know of far too many 15-20 year old systems still running, and
> the way things are, I suspect I still know a lot of them in five
> or ten years time, but then as 20 to 30 year old systems.
This is too simple a view of the way that any technological issue
effects our systems and institutions. Systems talk to each other -
systems are embedded in a larger ecosystem. Considering we just went
through all these issues with Y2K, it is discouraging that the
ramifications of changes to leap seconds and civil time standards in
general have been treated with such hubris and naive disdain.
> The only way we can compete economically with the existing proposal
> is if we can make leapseconds a non-issue for all users, operators
> and programmers and make them a concern for operting system
> programmers
> only.
But they aren't a non-issue. Solar Time has an important technical
effect on our civilization, but it also has legal, historical,
religious, philosophical and cultural effects. Like other issues
that effect our lives, Solar Time is best left exposed to view - it
is infrastructure that we must include in our planning.
Rob Seaman
National Optical Astronomy Observatory
Received on Fri Aug 12 2005 - 09:37:53 PDT
