[LEAPSECS] ISO Influence

[Joe Gwinn]

At 6:18 PM -0700 12/18/10, Rob Seaman wrote:

>  > But you forget an important fact Rob:  In computing UTC doesn't 

>have leap seconds presently.

>

>Computing is not the only game in town.  The world is layered on 

>systems and procedures that have assumed mean solar timekeeping for 

>hundreds of years.  The codebase we have has evolved with this 

>assumption - whether or not particular software systems have been 

>intelligently designed.

>

>>  So if we are to do what you call "Good Systems Engineering", no 

>>matter what we decide, if keep leapseconds, if have them with much 

>>longer warning or if we abandon them, we will have to review all 

>>software which may be buggy with respect to whatever definition of 

>>leap seconds we choose.

>

>Well argued!

>

>To quote the immortal Geddy Lee: If you choose not to decide, you 

>still have made a choice.

>

>>  Before we can do that, we need to find it.

>>

>>  So lets get started, we need to estimate how much time&money we need.

>>

>>  So how much source code can you review for leap-second sensitivity 

>>in an hour ?

>

>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.  The onus rests 

>on those who want to upset the apple cart.


There is a deep difference here:

In Y2K, there was going to be a discontinuity, the first occurrence 
of a "20xx" date in a computer world that had only known "19xx" dates.

By contrast, in the proposal to drop leap seconds, the periodic 
discontinuities would cease.  The default case is that people test 
their codebases in the absence of leap seconds, so the absence of 
leap seconds will cause them no added trouble.  It was mishandling 
the leap seconds, not their absence, that caused problems.


Joe Gwinn