Tom Van Baak wrote:
why in your opinion, are leap seconds OK but leap tenth-seconds, or
leap minutes, or leap hours not OK? Each of these preserve, to one
degree or another, the notion of stationary wrt solar time.
I'll refrain from references to current practice. We often get
tangled in assertion of "you can't do that!"
I would say that a leap tenth-second or leap minute are within the
bounds of possibility simply based on size. A leap hour is far too
big a jump. The point of intercalation is to make a succession of
changes which are individually of small enough amplitude to be ignored
(or, at least, ignorable).
The latency between intercalation events must be short enough to
permit smoothing over historical periods - say, a few decades. Too
short is also not good. I think tenth-second events would be needed
too frequently. Clearly some here believe one-second intercalation
events occur too frequently :-)
On the other hand, permitting a long delay between events - or rather,
between scheduling opportunities for events - risks losing the
corporate knowledge to handle the events properly. Others here
believe leap seconds are already demonstrating that :-)
One great benefit of leap seconds is that there is a simple mechanism
for introducing them into the flow of time marks. (The original
design is pretty clever, actually.) A leap minute would likely be
added as an additional last minute to the UTC day, basically 60
straight leap seconds.
I suppose a leap tenth-second would correspond to a slightly longer
final second to a day. One advantage of this is that (for the next
few hundred years) a rigid schedule could be instituted. Something
like add (or subtract) an integral number of tenth-seconds each and
every 31 December. The schedule remains fixed, the amplitude varies.
This has similarities to the various timeslicing schemes that were
mentioned - oh - five years into the discussion.
There are prior posts on why it would be very difficult to interpose
an additional hour, basically because hours are individually tagged in
each time zone, whereas each minute can cleanly add a 60th second and
each hour a 60th minute. That is, in Greenwich the leap hour could be
a 25th hour, but in Tucson it would fall between the end of the 17th
and the beginning of the 18th hours. (Among other logistical issues.)
So, with the caveat that I really do believe that we should be
focusing on collecting requirements to characterize the problem,
rather than speculating on possible solutions, here is a score card:
leap tenth-seconds:
small amplitude (too small? some might see these as rubber seconds)
too frequent operationally?
not so infrequent we could ignore them
split-second mechanism needed to implement
leap seconds
small amplitude
marginally too frequent (meaning people obviously disagree)
marginally too infrequent (to force programmers to handle correctly :-)
mechanism already deployed (obviously people disagree :-)
leap minutes
marginally acceptable amplitude (for some purposes, DUT1 would have
to adapt)
not frequent enough operationally (but not outside the bounds of
reality)
too infrequent to maintain corporate knowledge
mechanism possible
leap hours
unacceptable amplitude (waayy unacceptable)
not frequent enough operationally (by any interpretation)
too infrequent (whole civilizations would come and go)
mechanism is impossible
Like I said, if the alternative is the ITU giving up on civil
timekeeping entirely, we can likely reach some sort of consensus to
extend scheduling based on a relaxed approximation of some sort.
My personal preference is either to maintain the current status quo
(although extending the schedule without relaxing DUT1 should also be
possible) OR to redesign the system entirely from the ground up, eg.,
Steve Allen's zoneinfo concept.
There clearly is resistance to admitting that there are two different
underlying concepts of civil timekeeping that must both be honored.
Embracing this will be the quickest way to reach a new equilibrium.
Rob
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
