Re: leap second outage

[Harlan Stenn <stenn () ntp org>]

Jimmy Hess writes:
> On Wed, Jul 1, 2015 at 12:38 AM, Mikael Abrahamsson <swmike () swm pp se> wrote:
> > quickly. Either we should abolish the leap second or we should make leap
> > second adjustments (back and forth) on a monthly basis to exercise the code
> .
>
> See....  maybe there should some day be building codes for
> commercially marketed software  that provide minimum independent
> formal testing to be done by licensed independent testers,  including
> leap seconds and such. ^_^

And NTF's Certification and Compliance programs are going to do this.
At least as soon as NTF has the resources to get this moving.

> The leap second issues are possibly rare and intermittent,  therefore,
>  having a few per month  is not necessarily giving adequate exposure
> to code paths that may go wrong during an insert/del event.

If they happened every 6 month's time that would be often enough, but
the earth hasn't slowed down that much yet.  There will be enough times
that we could insert or delete one every month and still have |UT-UT1|
be under .9 seconds.

If it was announced that "starting in 6 months' time we'll be inserting
or deleting a leap second every month or so that would give folks enough
time to prep for it, and I'm pretty confident that the leap-second would
soon become a non-event.

> There's never been a negative leap second, only insertions, but how
> deletions are implemented  might expose new bugs, since there hasn't
> been one before,  And you can only have one leap per 24 hours,
> positive or minus,  pick one.

Yup.

> & Shouldn't this kind of 'exercise'  be done  during the QA process
> before releasing new system software,   rather than mucking with clock
> accuracy?

leap second handling is a "mechanism" question.  Which one to choose is
a "policy" question.  IMO, a vendor should provide adequate mechanism.
The customer should get to choose policy.

> There is a recent article with some Leap Second  'stress testing' code:
>       https://access.redhat.com/articles/199563
>
>
> Readily available test methods are available,  there ought to be
> little legitimate excuse for anyone writing serious software that has
> long-running processes or threads   not to include  evaluation for
> possible leap second  issues  and other possible clock-related issues
> such as clock stepping, DST, and Year 2038 in their standard smoke
> tests....

Yes.  And even so, testing these things takes time and equipment.
-- 
Harlan Stenn <stenn () ntp org>
http://networktimefoundation.org - be a member!