REMINDER: Leap Second

[Stephen Satchell]

On 01/25/2015 10:15 AM, Valdis.Kletnieks at vt.edu wrote:
> It shares another problem - that doing calculations across a boundary is
> difficult. If you have a recurring timer that pops at 23:58:30 on June 30,
> and you want another one in 2 minutes. do you want a timer that the next pop
> is at 00:00:30 - or 00:00:29? The operating system can't tell whether the
> desired semantic is "as close to every 120 elapsed seconds as possible" or
> "as close to the half-minute tick as possible".

I have automation code for a "classroom" full of Cisco routers, and the
way I deal with that sort of issue is to say that anything that has to
be synchronized to the wall clock uses cron(8), but for actions tied to
a fixed interval I use sleep(3) and let the operating system sort out
the issues, if any.  I did this to sidestep the issues with Daylight
Savings Time (DST) cusps; it also works for leapseconds, as the OS
interval timing is not tied to the real-time clock.

Funny you should mention ticks versus elapsed time.  In every
specification I've written since 1970, I've differentiated between the
two.  I got started doing that because in the computers of that era the
real-time clock was tied to power-line frequency, while the interval
timers were based on counts on a crystal oscillator.  The crystal was
using good for 1000 parts per million, good enough for short intervals.
 The power-line clock was pulled back and forth by the power company as
said company would fine-tune the time so electric clocks would stay at
the right time long-term as the expense of short-term jitter.

Today's computers don't use clocks derived from 50- or 60-hertz
power-line frequency.  The last computer I remember seeing with such a
clock was the IBM System/360.  The System/370 used a motor-generator set
for the power supply, so it had to get its real-time clock time source
another way.