Re: [LEAPSECS] Rubber seconds & need for different timescales

From: Rob Seaman <seaman_at_NOAO.EDU>
Date: Fri, 5 Aug 2005 09:02:03 -0700

Steve Allen writes:

> But all systems have rubber seconds, including systems which
> purport to be using TAI, including TAI itself.

As a limit this is just Heisenberg - all units are fuzzy if you look
closely enough. I don't believe civil time, and thus UTC, ultimately
hinge on such highly technical details. Rather, appropriate civil
time usage is as clear as the Sun in the sky. (Perhaps more obvious
here in Tucson than in some other locales.) It has been my assertion
since day one that civil time - and thus UTC - and thus leap seconds
- are not entirely, or even mostly, a technical issue.

However, to the extent that time does raise interesting and involved
technical issues, we would be much better off focusing on the bedrock
realities of experimental science such as Steve raises to resolve
these issues. TAI is of no intrinsic interest itself - it is a means
to an end in each case.

> There is no time scale which does not require ex post facto
> calculations in order to ascertain its actual meaning.

This is a broader issue than simply the handling of time. We can
make predictions about time - but ultimately, these predictions -
like all other scientific assertions - have to be put to the test
with measurements.

> Is a given practically-available realization of a time scale too
> rubbery for a given application? If so, put more money into the
> design of the system clock. But even having done so, if the system
> time needs to correspond to TAI, it has to have some way of
> introducing and tolerating rubberiness at some level.

Again - note that this is not some profound statement about the
swirling mysteries of time, rather it is a commonplace observation
about science and engineering. If an experiment requires heightened
stability in some regard, it is best to bring the offending parameter
within the boundaries of the experiment. If a system is being built
whose use cases imply requirements that can't be met by COTS
solutions (like TAI or UTC), then the project team needs to define,
design, implement, commission, test and maintain a targeted solution
to those requirements. It is not appropriate to transfer the
requirements of a few projects onto the entire rest of the world -
not appropriate for the world, but also not appropriate for the
projects themselves that will have failed to properly control the
variable they were concerned about.

> One size does not fit all.

There is nothing magic about TAI. It isn't the best time scale we
can design - it is simply the best time scale we have designed to
date - for certain purposes.

Rob Seaman
National Optical Astronomy Observatory
Received on Fri Aug 05 2005 - 09:02:25 PDT