[LEAPSECS] Merry Christmas!

Rob Seaman seaman at noao.edu
Tue Dec 23 11:04:21 EST 2008


Poul-Henning Kamp wrote:


> I have told you over and over, that if astronomers got their act

> together, they would get this upgrade in the blink of an eye if

> business which have real money riding on the leap-second could get

> rid of them.


Make us an offer. What have I ever said to suggest that I'm not open
to a bribe ;-)


>> At the very least, grep the source for terms like "DUT1" to search

>> for the Y2K-like issues.

>

> This, again, shows that you simply don't understand what our trouble

> is. We do not need to grep for DUT1, because it's not there, we

> don't care about DUT1.


So no naive subcontractors put DUT1 in after reading the ITU UTC
document? And nowhere in any of these systems does UTC meet GMT
derived from some legacy source? It isn't whether you care about DUT1
- it is whether you are dependent on it. If the Y2K-like strings
aren't there, it should be little trouble to grep for them.

You appear to believe that your argument is with me. Rather, we're
all arguing with the ITU.


> What we need to do, at every single leap-second, is to sit and

> monitor N computers, to see if they all agreed about the existence

> of the leap-second, if their operating systems all did the

> standards-mandated stupidity of replaying the 23:59:59 second in

> unison and if any applications croaked because of that.

>

> If the computers are hooked up to important or dangerous hardware,

> we have to stop that hardware before the leap-second, and start

> it again afterwards.



Yes, I understand this. If you want this to influence decision-
making, document it and attach it to a coherent systems engineering
management plan.

However, if you really believe you are fixing your systems by seeking
to limit the inputs to those systems, you are only setting yourself up
for other classes of failures. Are leap seconds the only glitch the
systems might ever see? Surely subsystems should validate their own
inputs.

Rob


More information about the LEAPSECS mailing list