Re: [LEAPSECS] Rubber seconds & need for different timescales: was Stupid question from programmer: Why not just eliminate ALL UTC corrections ?

From: Steve Allen <sla_at_UCOLICK.ORG>
Date: Fri, 5 Aug 2005 07:21:03 -0700

On Fri 2005-08-05T15:45:56 +0200, Poul-Henning Kamp hath writ:
> >Whether rubber seconds are usable or not depends on
> >what problem you intend them to be a solution to.
>
> Rubber seconds are _never_ usable, just like
> rubber meters, rubber kilos and rubber unit charges
> are never usable.

> We could label everything on TAI and be happy ever after.

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

We can surely hope that there will never again be a frequency step in
TAI of 1 part in 1.e12 as there was in 1977. We may be able to hope
that there never again will be a frequency glide of several parts in
1.e14 as there was in the late 1990s. See TT(BIPMxx) for details of
these.

The publications of the BIPM admit that there is currently some sort
of frequency offset in TAI which may someday be corrected.

It is evident here
http://tf.nist.gov/pubs/bulletin/nistat1.htm
that NIST is continuing to steer its frequencies by several parts in
1.e15 as a routine operation.

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

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.

One size does not fit all.

--
Steve Allen                 <sla_at_ucolick.org>                   WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165       Lat  +36.99858
University of California    Voice: +1 831 459 3046              Lng -122.06014
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/        Hgt +250 m
Received on Fri Aug 05 2005 - 07:21:25 PDT

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT