[LEAPSECS] Testing computer leap-second handling

Rob Seaman seaman at noao.edu
Mon Jul 9 09:41:24 EDT 2012


On Jul 9, 2012, at 5:24 AM, Gerard Ashton wrote:


> I just read an explanation of what went wrong with some Linux systems:


Yes, that and the Landslide analysis are very good. I also found PHK's comments on leapsecs to be illuminating from the FreeBSD perspective.


> It would be tempting to prepare for the next leap second by running a fake leap second into a test system that is sitting in a lab doing nothing but keep time. But a realistic test requires that the system under test be running a load as similar as possible to production systems.


Whatever else is true, it's clear that insufficient testing occurred. As Y2K lead for my group I kept a system set ahead to a date in the 2000's for a couple of years beforehand. Plus 11 years I think it was, since the 2010/2011 New Year's Eve resembled the Millennium (day of the week, preceding year not a leap year). This permitted innumerable tests in advance.

The corresponding leap second tests are different, but the need to test edge cases is similar. Here it doesn't look like a serious attempt was made even to test the basic functioning (not on loaded systems certainly).

It is quite likely that another leap second will occur before 2015; it is a near certainty there will be multiple such before 202N when any change would take effect. Putting aside our diverse policy positions, members of this mailing list have worked for many years to raise the profile of UTC issues. Perhaps this will be easier now, and we should be able to identify common cause in encouraging such testing, and in general in educating various communities about timekeeping issues.

Rob



More information about the LEAPSECS mailing list