> : > 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 [EMAIL PROTECTED] _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs