Re: [LEAPSECS] Wall Street Journal Article

From: Rob Seaman <seaman_at_NOAO.EDU>
Date: Sat, 30 Jul 2005 10:20:42 -0700

On Jul 30, 2005, at 12:05 AM, Poul-Henning Kamp wrote:

> I have three times been through what ended up being total reinstalls
> from backups because some operator by accident (or stupidity) set
> the clock forward in time and then backward in time on a database
> installation.

Are you asserting that these problems had something - anything at all
- to do with leap seconds? If you were the one cleaning up the mess,
presumably you had something to do with hiring the operators and
documenting their operating procedures. Poor management of software
systems doesn't seem like a strong justification - or even
rationalization - for changing a completely unrelated international
standard.

The solution to ignorance - what you so generously characterize as
"stupidity" - is education. You are really just supporting the tired
old notion of security through obscurity. As the traffic school cop
pointed out: there are no accidents, only collisions.

> Your workstation is not an "IT installation", it is just a
> workstation.

I was our Y2K team lead. For that period of time, my workstation was
one of the primary development systems for an image processing
software package used by half the astronomers in the world. The
astronomical community responded promptly and appropriately to Y2K,
with initiatives such as formally adopting ISO 8601 and introducing
pivot dates into systems that had to remain backwards compatible.
Coherent APIs were designed and implemented to handle both new format
and old format date/time strings transparently.

Why are we not discussing what new data structures, APIs, transport
protocols, deployed systems, operating procedures, staffing and
management issues will be necessary to implement such a major change
less than two-and-a-half years hence? How is it that this "proposal"
is completely devoid of any discussion whatsoever of its
implementation and ramifications?

UTC is the equivalent of ISO 8601 for the purpose of this never-
ending discussion. In point of fact, many ISO 8601 compliant strings
embedded in your databases implicitly assert that UTC ~ GMT.
Whatever happens to leap seconds in the future, proper interpretation
of your archival records will continue to depend on interpolating the
appropriate leap seconds. Or actually - not. Precisely because UTC
~ GMT, typical civil usage allows you to completely ignore leap
seconds when interpreting past data records. Rather, proper
interpretation of your *future* database records may well require
explicit time scale conversions. There is a vast web of implications
associated with civil time. Trying to sneak through a major change
of philosophy to an international standard simply to avoid having to
think about its implications seems craven and intellectually dishonest.

Why are tired, inaccurate and unconvincing leap second risks treated
like plutonium is raining from the sky? And why are the subtle and
real risks associated with violating the implicit assumption that
civil time corresponds to Greenwich Mean Time ignored completely?
GMT - and its successor, UTC - is a standard that has been in place
since the nineteenth century. Wouldn't it make sense to conduct a
risk analysis in advance of violating that standard worldwide?

Rob Seaman
National Optical Astronomy Observatory
Received on Sat Jul 30 2005 - 10:20:50 PDT