Re: [LEAPSECS] Internet-Draft on UTC-SLS

From: Rob Seaman <seaman_at_noao.edu>
Date: Thu, 19 Jan 2006 16:32:25 -0700

On Jan 19, 2006, at 2:33 PM, Ed Davies wrote:

> With this method (4a) UTC-SLS would not have the property listed in
> section 3: "the time always equals UTC at full or half hours". I
> think this is a valuable property; as the text following the 4a), 4b)
> and 4c) options notes: "...would be reached at midnight, which is a
> time commonly used to schedule events and deadlines."

Valuable indeed.

The great thing about purely technical discussions (as opposed to new-
age theology - such as leap hours - masquerading as technology) is
that one can rely on them converging on a practicable, self
consistent, consensus. I suspect neither Kuhn's or Kamp's proposals
will be adopted in a closely recognizable form, but they may well
inform and improve future timekeeping designs now that they have
found a forum.

It is the underlying reality that is not self consistent. An
interval time unit such as the SI second can be coherently defined.
An Earth orientation unit of time such as the "day" can also be
coherently defined. Note that I don't indicate that defining either
is trivial - pesky general relativity, for instance, makes sure of
that - but they each are suitable candidates for self-consistent
definitions, useful for various and sundry purposes.

But they are not the same thing. They are not coherently expressible
one in terms of the other. This is not necessarily an issue. What
makes it so is that the requirements for civil timekeeping - unless
we completely redefine the notion of same - require that we pretend
that the two things are one.

Marcus Aurelius asks us to ponder:

        "Ask yourself, what is this thing in itself, by its own special
        constitution? What is it in substance, and in form, and in matter?
        What is its function in the world? For how long does it subsist?"

(Also Hannibal Lector to Agent Starling in "Silence of the Lambs".)

Until we can reach a consensus on the nature of civil time (or even
on its separate existence), we won't make headway on finding a single
technical solution to all civil timekeeping issues. That being the
case, one might be tempted to suggest that we don't even try, but
rather look for separate solutions to various pragmatic classes of
timekeeping needs. Glad to see the list moving in that direction.

Rob Seaman
NOAO
Received on Thu Jan 19 2006 - 15:33:07 PST