[LEAPSECS] rubber seconds in Japan!

[Tom Van Baak]

>>100 of them, just before the leap

> 

> This is essentially the same technique as Markus Kuhn's UTC-SLS (UTC

> with Smoothed Leap Seconds), but over a shorter period.  One might well

> suppose that if they'd heard of UTC-SLS then they'd have used it, and so


I think we covered this back when we debated UTS.

The idea of speeding up and slowing down ticks to handle leap
seconds (or other timing discontinuities) is not new. It is one of
several practical ways to avoid a clock reading :59:60. It's also
not unlike how a PLL works.

The problem with UTC-SLS, last I read it, was that it demanded
a smoothing factor of 1000. This rate change is unnecessarily
high for many applications and unacceptably low for others.

One can imagine perfectly workable smoothed leap second
solutions using not just 1000, but instead 100, or 1024, or 60,
or 30, or 10, or 2, or 1/2. Or if you're perverse, 86400.

In every case it is simply a trade-off between the magnitude of
frequency excursion and the duration of smoothed leaping event.
Some systems have frequency limits; others may have time limits.
There is no one solution, nor should there be. There may also be
hardware considerations. For example, if a 32 kHz-based clock
were to re-synchronize smoothly it would be more convenient to
use a binary factor like 16 or 1024 rather than a decimal factor
like 100 or 1000.

I like their centisecond solution. Do we have anyone from Japan
on the list -- it would be nice to add a recording of this event to
my leapsecond collection.

/tvb
http://www.LeapSecond.com