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. ^_^ 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. 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. & Shouldn't this kind of 'exercise' be done during the QA process before releasing new system software, rather than mucking with clock accuracy? 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....
-- Mikael Abrahamsson email: swmike@swm.pp.se -- -JH