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!