So, the assertion is that an imaginary requirement that technology
worldwide must remain synchronized to the fractional second level at
all times in all places forever and ever - that this takes precedence
over the actual (if heretofore largely unstated) requirement that
historians and long term planners (and yes, some folks do think
thousands of years into the past and the future) need a coherent
system for tracking clock relationships between countries and centuries?
The real issue is and has been the quadratically increasing rate
differences between atomic and solar time. Technology wants a stable
rate. We live (in our manifold civil time scheduled ways) on a
slowing platform. Interval timekeeping has one set of requirements.
Civil timekeeping has another.
Solutions for "applications" can and should rely on properly designed
systems, not on kludges involving telling, for instance, the
historians of the world that they will never again be able to keep
track of relative clock time during battles and negotiations and
journeys.
There are two kinds of time. They demand two clocks. UTC manages to
convey both, but if you want to throw this useful feature out, you
will still need two kinds of clocks.
Planning first requires recognizing the full scope of the problem. If
you don't like leap seconds, track the difference using Allen's
zoneinfo system. Or suggest your own system. There has been a fair
amount of support on this list for exploring the notion of stabilizing
the leap second scheduling algorithm. Most suggestions floated so far
are even potentially in compliance with the current definition of
UTC. If a lack of predictability is really the issue with leap
seconds, explore these options.
Rather, a unilateral and relentless campaign has been followed with
the singleminded goal of eradicating leap seconds entirely. Between
repeated cycles of attempting to fend off this campaign, there has
been no time to actually attempt to solve the problem you assert.
We live on a planet with charmingly irregular motions. Attempting to
ignore this fact will inevitably fail, perhaps spectacularly.
Rob
---
On Dec 18, 2008, at 11:47 AM, John Hein wrote:
John Cowan wrote at 11:15 -0500 on Dec 18, 2008:
Rob Seaman scripsit:
Because the past remains with us, and the future requires planning.
In addition to what John Cowan said, I'd also point out that planning
is the one of the biggest issues with leap seconds.
In terms of planning for the future, if an application cares about
local time, not knowing whether a leap second is going to happen
outside a six month window can be a much larger problem than handling
sliding time zones that would happen much less frequently and, one
would think, with considerably more advance notice.
For those that are in favor of the current system of leap seconds, it
might be more effective to pretend that people don't have to plan for
the future than to remind them in the opening sentence.
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
