[LEAPSECS] ISO Influence

[Poul-Henning Kamp]

In message <FB2CED2D-4C10-4A48-9751-45FCBB3B75EF at noao.edu>, Rob Seaman writes:


>Got me.  I suggest reviewing Y2K postmortems for pertinent estimates.

>The proposal on the table (that has nothing to do with either one

>of us) is inept and absurdly incomplete.


That's your opinion.

I personally think it is a pretty smart decision, as it means that
99+% of all programmes will not have to be changed, as their idea
of UTC becomes the standard.

This in effect means that software review and changes can be limited,
more or less, to any program that reads an ephemerides or star
catalog file.

Those programs are overwhelmingly written by and used by people with
"phd" after their names, so the level of competence involved is waaay
higher than all the commercial code in banks, credit unions etc.

I don't think using Y2K metrics to estimate reviews for leap-second
trouble is valid, it would underestimate the effort needed, as both
Warner and I have learned the hard way:  The issues involved are
much trickier than a mere numeric rollover.

Magnus writes:


>I don't think the leap seconds as such is necesserilly a bad thing, but 

>I do see the points about them being problematic to "bake into" the 

>system. If they where known to a greater extent in advance, it would 

>resolve some of those issues. It would still require the fix of software 

>as such


My estimate is that if we get 10 years advance notice, we can eliminate
90-99% of the software from the review, because the current POSIX hack
can be distributed preconfigured in operating systems.

Gerard writes:


>Poul-Henning Kamp made some inquiries about how quickly Rob could review 

>code. I suggest this question misses a few important items.


Actually it doesn't.

Initially I simply wanted to estimate how long time the first sweep
of reviews would take:  The time to identify source code which may
have leap second issues, as opposed to source code we can say with
certainty will not.

For instance, the implementation of the sqrt() would be bogus indeed
if it could have leapsecond issues, we don't need to spend time on that.

But routines handling lock-files, or database updates needs to do
the right thing during a leap second, and we need to find the names
of those sourcefiles.

I don't expect Rob or me to be involved in the first-level sorting,
but by taking a highly qualified person like Rob's performance as
benchmark, we can put a very rigid lower bound on the time we need
to complete the first-level sorting:  It will never be faster to
let anybody else do it.

Robs continued evasion of the question is because he know that the
number we will divide his estimate into is enourmous, and thus fatal
to either his "proper systems engineering" or his "nobody knows the
cost" argument:  Either we will have to skip the review, or the
prospective cost will be enourmous.

Poul-Henning

-- 
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.