[LEAPSECS] Schedule for success

M. Warner Losh imp at bsdimp.com
Mon Dec 22 13:35:20 EST 2008

In message: <8B194364-41A0-4565-9F5A-4DC99219BFC5 at noao.edu>
Rob Seaman <seaman at noao.edu> writes:

: So many messages, so little time!


: M. Warner Losh wrote:


: > In general, all systems need to be synchronized to human time

: > because at some point they have to interact with humans.



: Right. And human time is synchronized with mean solar time because

: we happen to live on the planet Earth. What we are debating is how

: this synchronization should happen and on what schedule.

No. We're synchronized with mean solar time at an arbitrary location
on the globe that happens to no longer even be on the prime meridian
anymore since GPS' new definition of the geoid. And we're not
counting 'natural' seconds anymore either: they are based on
oscillations of atoms, not on the rotation of the earth. Who the flip
cares of the 'prime' meridian (defined as the places where 0:00:00
corresponds to midnight astronomically) drifts a bit. It just doesn't
matter to people.

: > Sure, it usually doesn't matter much, and you can usually get away

: > with it, but that reason alone is not sufficient to say it is never

: > a problem.


: No, but it is a good argument for following a coherent and

: transparent decision-making process, and for not rushing into a bad

: decision.

True, but not relevant to this discussion. You often conflate the
decision making process of some committee with the current leap second
system. They aren't relevant to discussing the current problems.

: > Since we've only been using them for 40 years, there's no real

: > posterity to worry about.



: No. We have been using mean solar time formally since the 19th

: century, and informally since we woke each morning to light shining

: through the entrance of the cave. Leap seconds are simply the current

: mechanism for instituting a civil timescale based on mean solar time.

No. We've been using leap seconds for 40 years. We used actual local
solar time before the 19th century for a few thousand years before
that. The main benefit of using standard time zones is everybody
using the same time. It isn't that it is mean solar time, that just
happened to be one way to define things that is arbitrary based on
some set of aesthetics. It was useful when the second was not
realized precisely enough to there to be a difference between the
second and 1/86400th of the day. Now that we've defined the second to
not be 1/86400th of the day, the aesthetics of the situation has
changed. We should really consider if it still matters to have things
based on mean solar time at an arbitrary meridian, or if such a
coupling really matters at all. This is the crux of the debate: I
think it is silly, you think it is so obviously critical that we can't
find common ground on this point.

: > Since we're going to have to have them with increasing regularity

: > over the next 50 years, to the point where 2 a year are unlikely to

: > be enough, we need to ask ourselves if there's some better way to

: > distribute time than what we're doing.


: The frequency over the next 50 years will be similar to the past 50

: years, and likely for a couple of centuries after that:


: http://six.pairlist.net/pipermail/leapsecs/2008-January/000184.html


: It would be delightful to discuss better ways to define and distribute

: civil and professional timescales. It is hard to find time to do this

: after 9 years of persistent attempts to rush to judgement.

The frequency of the next 50 years is likely to be higher than that of
the previous 50 years because the earth's deceleration has been
accelerating. Of course, given how hard it is to predict the rotation
of the earth, who can say for sure. I'm afraid I don't have a paper
reference for this, I learned of it talking with Judah Levine one day
about other issues (like why he was seeing issues with the measurement
system my company had deployed for him). I've heard others on this
list refer to it as well.


More information about the LEAPSECS mailing list