Re: [LEAPSECS] Leap second status?

From: Rob Seaman <seaman_at_NOAO.EDU>
Date: Tue, 3 Dec 2002 12:15:10 -0700

John Cowan replies to my hyperbole:

>> There is no possible way that society would overlook some goofy scheme
>> put forward by us pointy headed poindexters that results in the sun
>> rising at midnight (yes, yes - in mid-latitudes). That is one
>> inevitable result of terminating the issuance of leap seconds.

> I don't think anyone proposes *that*. Rather the desire is to make
> them predictable over the medium-long term.

Well, actually - terminating the issuance of leap seconds is the only
proposal still remaining on the table:

    "1. The group voted to exclude from consideration all redefinition
    options except freezing the number of leap seconds at some so-far
    unspecified date. This means they won't try to change the definition
    of the second from 9,192,631,700 periods of a certain hyperfine
    transition of the undisturbed cesium atom, replace leap seconds
    by leap hours, etc."


If the link doesn't work you may have to go to the archive and manually
register: Then search on:

    From: matsakis.demetrios_at_USNO.NAVY.MIL
    Subject: Meeting of ITU/R Special Rapporteur Group
    Date: 28 Mar 2002

Again - it seems to this observer that this whole process is occurring
at a pace many times faster than is warranted by the situation. The
group met - and the group voted to exclude all possible options except
one. Are all of the "ITU/R Special Rapporteur Group" even members of
this list? Or perhaps is there some other mailing list or mechanism
for technical or other discussions among that group?

> In fact it will be necessary to *rebuild* the world's clocks at some
> future date, when it no longer becomes plausible to claim that solar
> days constitute 24 hours of 60 minutes each.

And how precisely does rebuilding our clocks help? Can anyone suggest
a specific fix for this problem? Will a day consist of something other
than 86,400 seconds? Shouldn't we have the details of a new solution
in mind before we throw the old solution out?

John further replies to my message:

>> And so, might I humbly suggest that whatever changes may be made to
>> the UTC standard - now or in the future - that the new standard specify
>> a solution that is complete indefinitely far into the future?

> Unless I am missing something, no such solution is possible, given
> the constraints we have put ourselves under (civil day must stay close
> to solar day, second must have current length, clocks can't redesign
> themselves to display more minutes/hour or more hours/day).

A possible far future option is touched on in passing at:

(my message, "Upgrade, don't degrade", 9 April 2001)

In summary, a long term solution is to periodically (like every few
thousand years) redefine the second to handle the long term trend,
while continuing leap seconds to handle the short term wiggles in that
trend. This places the burden of supporting the new standard where it
belongs - with the technical and scientific communities. Clocks will
naturally pick up the new standard on a pace rapid enough (meaning
glacial enough) to vanish into the world's economic soup.

Alternative solutions - *independent* of any retooling of our clocks -
require that our species change to the point that technology matters
more to us than the variation between night and day. A pretty future?

But the real question isn't musings on issues that will only concern
our far future decendents. The real question is whether we're going to
shoot ourselves in our collective foot over a question of why certain
technical projects can't utilize the current TAI/UTC standard correctly.

If they can't handle the current standard - why should we think they
will handle changes to that standard any better? And by masking the
real issues, aren't we making major technical problems more likely -
rather than less?

The solution is indeed to upgrade the infrastructure, not degrade it.

Rob Seaman
National Optical Astronomy Observatory
Received on Tue Dec 03 2002 - 11:28:37 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT