[LEAPSECS] Of stepping motors and leap seconds

[Steve Summit]

tvb wrote:
> After visit to USNO years ago I wanted to make a leap second desk clock...
> I've hacked such clocks in the past; it's quite easy.

Oh, my.  That sounds like a crazy project (and I mean that in the
best possible way), but it's not so far from a project I did,
and one I'm thinking about.

At

	https://www.eskimo.com/~scs/time/xclock-anim-short.gif

you can see an animated screen capture of a modification I made
to the standard Unix/Linux xclock program.  I was pleased with
the way it came out: the alteration during the last minute ends
up being nicely subtle, much less jarring than I had first
anticipated.

> Note that if you have a digital display no smear is necessary
> since you can drop a :59 or add a :60 with ease. LED or LCD
> digits display instantly. But if you have a "real" clock, one
> with analog hands, you can neither display a :60, nor drop a :59...

Indeed, and the xclock animation (with its digital version
beneath) demonstrates that distinction nicely.

As written the xclock modification works if one of the "right"
tz zones is in effect.  It would require some different logic to
work properly with a leapsecond-aware OS kernel.  (I think the
adjtimex call would be able to give it most of the information it
needs, but it might be dicey.)  The issue is that as written the
analog clock has to be able to anticipate an upcoming leap second
a minute before it happens; it can't merely react to it as a
digital clock can.  (There are some lessons here for API design,
I guess.)

I also have a detailed plan in my head -- I'm not sure I'll
ever manage to implement it -- for a computer-aided mechanical
pendulum clock.  A solenoid-driven clutch on the escapement would
enable any given swing of the pendulum to advance the clock by
anywhere from 0 to 2 seconds.  It would make slight adjustments
all the time, to stay in sync with the computer's NTP feed.
At 1am on a Spring DST adjustment it would run 2x fast for an
hour to spring forward; in the Fall it would stop for an hour to
fall back.  And during a leap second it would quietly do whatever
the OS does, which at worst would be a 1s slowdown whenever the
OS chose to drop the second.  (Since pendulum clocks typically
don't have second hands, you can get by with more fudging.)

> These ideas were inspired by a vintage Junghans DCF77 / WWVB
> analog clock. During synchronization it enters a rapid tick mode...

Yup.  (Mine too.)

> Now back to Google and its ~24 hour smear. One feature of their
> approach is they center the smear around midnight.

Yup.  Me, I dislike that.  I understand the appeal, but it just
feels wrong.  Leap seconds "happen" on June 30 and December 31,
so to my way of thinking, any smear or other games should be
confined to that day.  (My first leapsecond-aware kernel
implemented a smear which started at a configurable point during
the day and always ended at precisely midnight, but I had to
abandon it and start over, among other reasons, so that I could
implement the "symmetric" smears that everybody else seems to be
pursuing.)

> I'm wondering how the LEAPSECS crowd feels about long or short smears.

One way of thinking about it is that it depends on what you're
trying to minimize.

If all you're trying to do is get rid of leap seconds (for the
benefit of ALL the leapsecond-unaware code that can't handle
them), you want to smear over a long period, to minimize the
change in the length of a second, and to avoid sharp corners
on the derivative.

If you *do* have a leapsecond-aware application, on the other
hand, you obviously won't be using smearing at all, so the
question is moot.

And then if you're trying to write a leapsecond-aware kernel,
that can support leapsecond-aware applications properly, while
also doing in-kernel smearing for the benefit of all the
leapsecond-unaware applications also running there, you might
want a short smear, to minimize the time interval over which
two different time-reporting calls report different times,
on the same machine.  (It's bad enough if two different otherwise-
synchronized machines report different times -- this is of course
one of the evils of smearing -- but it's even worse if it's the
same machine.)