Re: [LEAPSECS] Wall Street Journal Article

From: Rob Seaman <seaman_at_noao.edu>
Date: Fri, 29 Jul 2005 14:58:28 -0700

On Jul 29, 2005, at 2:11 PM, Poul-Henning Kamp wrote:

> And 62 o'clock happened precisely because leapseconds are
> untestable in practice for programmers.

 From 1998 to 1999, I left the clock on my desktop Sun workstation
set forward 11 years. This allowed me to test various Y2K
remediation issues. (The 11 years was to select the next year with
the same monthly calendar.) There is nothing untestable about leap
seconds in either theory or practice. The international triumph that
was the non-story of Y2K is proof that time dependent code can be
inventoried, characterized, remediated and tested in advance. I am
proud of the modest part I played in this for the astronomical
community.

One imagines the proponents of the "private matter internal to the
ITU" trotted out each and every example they have of leap second
glitches for the WSJ reporter. And one has to wonder if the rather
paltry list compiled by this most business-friendly of publications
won't be dwarfed by bugs revealed if the equivalency between UTC and
GMT is allowed to break. It seems particularly inappropriate to
regard the Motorola bug as a "leap second bug" when it represents a
class of bugs that will only be revealed should leap seconds cease.

I certainly hope that bad-engineering does not expose the public to
safety hazards on New Year's Eve. Perhaps proponents of the "U.S.
Proposal [...] not for public discussion" might show a little
humility and consider commissioning a risk analysis in advance of
changing a standard that has been in place since the nineteenth
century. What is possibly gained by neglecting this elementary
precaution?

Rob Seaman
National Optical Astronomy Observatory
Received on Fri Jul 29 2005 - 14:58:49 PDT