> > You cannot divide timekeeping, time dissemination,
> > into neat stages. In the 1960s if ten labs were told
> > to offset their phase or frequency it affected only a
> > handful of people or systems. Today when IERS
> > announces a leap second, millions of machines,
> > systems, and people are affected. Thankfully, most
> > of them handle it OK.
>
> Although, even now, the majority of consumer and business equipment
> is not directly affected in any noticeable way; such machines usually
> run on a local clock considerably less accurate than an atomic clock,
> periodically re-synced (perhaps manually, perhaps automatically) to
> an external time standard.  At each such re-syncing, the time may
> need to be adjusted by a few seconds, or even a few minutes, due to
> inaccuraccies in the local timepiece, so any leap second that may
> have occurred since the last syncing will merely result in a 1-second
> difference in the magnitude of this adjustment, not particularly

Correct. This works for timepieces which are less than
accurate to the second. And I believe this is why UTC
and leap seconds are still today the most practical and
accepted way to reconcile the unavoidable difference
between astronomical and atomic timescales.

The danger, though, is that in the 60s maybe ten systems
were affected by leap seconds. In the 80s maybe a
thousand. Today, the number of systems affected (or is
it infected?) with leap second awareness is in the millions.

I worry about this trend in the decades to come. I am
a fan of leap seconds as a weird and curious nuisance
but am not sure I like the idea that eventually my car,
traffic lights, airlines, television, and my thermostat will
have to be reliably tied to the IERS in order to function
properly.

Don't forget the quartz wristwatch is only 40 years old.
What if cesium wristwatches show up 10 years from
now. What if some killer app 40 years hence requires
100 ms or 1 ms time accuracy. Do we still want UTC
leap seconds when it will infect ten billion devices?

This is not an argument for change right now. But no
matter how you look at it the current scheme does not
scale well into the future; either a technological future
(way too many devices affected by unscheduled time
steps) or an astronomical future (way too many leap
seconds a year).

> noticeable to the end users.  If some application (e.g., a database)
> requires a timescale without discontinuities, the application might
> need to be shut down for a few seconds to perform the time adjustment
> (whether or not there is a leap second in the mix) in order to
> prevent data corruption at the moment of the change.

I would guess your total shutdown "solution" gets less
popular as time goes on. That's one reason why CDMA
cell phones, most operating systems, and GPS use a
TAI-like continuous timescale instead of UTC for their
underlying timescale.

/tvb

Reply via email to