Re: [LEAPSECS] What problems do leap seconds *really* create?

From: Steve Allen <sla_at_ucolick.org>
Date: Wed, 29 Jan 2003 15:10:28 -0800

On Wed 2003-01-29T15:43:24 -0700, Rob Seaman hath writ:
> Please! Let's talk about ways to improve UTC and civil timekeeping.
> And let's take the appropriate amount of time to reach a decision -
> say - 40 or 50 years. In the mean time, let's pay attention to the
> real question, which is how to build an infrastructure that will
> dramatically improve the dissemination of all time signals.

Alas, we do not have 40 years, we have less than 35. The end of
32-bit Unix time is 2038-01-19T03:14:07. Well before that the Unixes
of the future must have decided on the proper way to implement the
algorithms for handling 64-bit time_t when receiving inputs from the
NTP(s) of the future.

Although there are many technical aspects to the situation, for
practical purposes any change of UTC is legislation. Effective
legislation seeks the common good while remaining congruent with the
will of the people. When that will is split because of pre-existing
practices and notions of what is good, the process inevitably becomes
political. If this change is going to affect civil time, then,
politically speaking, the 32-bit end of time is a looming deadline
that should serve to motivate an answer about the fate of UTC within
the next 10 years.

In the mean time we may learn that a fifth fundamental force has
implications for the spacetime metric that invalidate all the current
time scales in use by astrophysics. As before, the response to that
kind of paradigm shift in physical thinking would trigger the creation
of yet more time scales to be used by astronomers. The old time
scales would remain, unmodified, and less used.

On Mon 2003-01-27T17:32:19 -0500, John Cowan hath writ:
> I would have no problem with deciding now to change UTC, effective in 2033.

Over that interval all the observatories in the world could assuredly
handle any change. But in the context of the history of time scales,
changing the character of UTC would still be the wrong thing to do.

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla_at_ucolick.org      Voice: +1 831 459 3046     http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E    49 89 0E FE 26 B4 14 93
Received on Wed Jan 29 2003 - 15:10:46 PST

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