[LEAPSECS] How good could civil timekeeping be?
phk at phk.freebsd.dk
Fri Feb 15 09:01:50 EST 2008
In message <4F2EE2CE-6061-4786-AD92-7176F8B2E9A0 at noao.edu>, Rob Seaman writes:
>> 3.The only thing worse than generalizing from one example
>> is generalizing from no examples at all.
>Right. Which is why you invest time and money in seeking out (or
>eliminating) possible examples. I have access to examples of
>astronomical software (and also have experience from having performed
>our Y2K inventory). As we've discussed far too many times, changing
>UTC will definitely require changing astronomical software extensively.
There has never been any dispute that astronomy software would
need adaptation. It follows from the mechanical physics of the
I think I can also safely say, that astronomy software is less than
one PPM of all software on the planet, no matter what metric.
It is all the non-astronomy software we disagree about.
So far I have yet to see one single example of non-astronomy software
that needs changed to handle loss of leap-seconds.
To my knowledge you have not found any either, or I pressume I
would never have heard the end of it :-)
Given how much software we have seen between the two of us, that
brings the probability of finding any such software well below 1%,
quite likely to virtual zero, by which I mean that it will not
be found by anybody until it misbehaves.
In the other corner, I can point to any and all software that
includes <time.h> as candidate software that needs to be audited
for correct leap second handling.
Purely from a cost perspective, any reasonable economist will at
this point lean heavily towards throwing leap-seconds out.
To move the statistics in your favour, heavy-duty evidence will be
The first thing you have to do, is turn the "virtually zero"
into "non-zero" by finding at least one piece of software outside
the realm of astronomy, which would be adversely affected by the
discontinuation of leap-seconds.
If you tasked me with that, I would have no idea where to even
Absent that pivot for the class, you are generalizing from no
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the LEAPSECS