[LEAPSECS] Terminology and Requirements (was Re: How good could civil timekeeping be? )

[Tim Shepard]

> : > And down at a hairsbreadth, you cannot by looking at a time_t value,

> : > tell the leap second from the second right before it.  (In some

> : > cases it's the second after, but that's clearly a bug since the

> : > leap second is the last second in the preceeding 24 hour UTC period.)

> : 

> : Rubber seconds solve this problem.

> 

> No they don't.  Rubber seconds are even more evil than leap seconds.



I think the problem here is one of terminology.  We all just don't
agree on precisely what these words mean.  

When we discover that we have different meanings in mind for words,
it might help in discussions like this to somehow find a way to agree
on terminology.

For example, the term "seconds" means different things in different
contexts.  When we conflate the two contexts without realizing that
there may be conflicting requirements in the two different contexts,
our discussion isn't likely to produce fruit.


I agree that rubber essens would be evil.  (Ignoring for a moment that
if you just look a few more decimal places to the right, you discover
that there's some residual rubberiness that just will never go away.)

But rubber seconds are simply a fact of living on this planet.
(Sorry I cannot think of a neutral alternative to the word "second"
 here.  Any suggestions?)


It is true that if you make 1 essen close enough in value to 1 second,
you can pretend there is no difference for many years.  And that's
essentially what we do for six months at a time (and often longer) in
most contexts.


I sometimes wonder how sure we can be that the synchronized ticking of
UTC and TAI will be maintained without interruption.  Yeah, we can be
pretty sure, but there may be cases where it's better to base time on
something that we can be sure can be recovered no matter what.


Maintaining some residual know-how of how to do celestial navigation
in case (heaven forbid) we wake up some morning and discover GPS is no
longer available is a Good Thing, in my opinion.

And I believe civil time scales should be defined in a way such that
in case there is ever any dispute or disruption, there is some
neutral and objective way to recover it.  (A Nautical Almanac, a
small telescope, and a timepiece to be set (or logged), and I can
recover it.)

If the TAI/UTC synchronized ticking were lost for awhile, what would
happen then?


We should be careful how we make the master dependency diagram for
this this ever-increasingly technological world.  Independence brings
robustness.  Too many dependency edges creates brittle infrastructure.


There is no faster way to make my eyes glaze over than to suggest we
should work on a Requirements Document.  It is much more fun to invent
technical solutions.   But I believe at this point, we have no hope of
getting to an agreement about What Should Be Done without carefully
documenting what all the applications are that need to be supported,
what their requirements for timekeeping are, and then analyzing how
the requirements mesh and conflict.

When I run that scenario in my head, I see no escaping that we need
more than one time scale, and the existance of more than one time
scale will need to be somewhat more exposed.  We already live in a
world with more than one time scale, except that the fact that more
than one time scale exists is often papered over and/or neglected.
(And that is when problems start to surface.)  Perhaps this could be
documented (or refuted) more carefully, while avoiding ambiguous
language.


			-Tim Shepard
			 shep at alum.mit.edu