[LEAPSECS] honest-to-god copper

[Rob Seaman]

On Jun 8, 2010, at 2:05 PM, M. Warner Losh wrote:


> Most applications that have a civil timekeeping requirement tend to

> have a large tolerance for errors.  "Good enough" time keeping that

> gets some details wrong, but produces more intuitive results is often

> sufficient to meet the applications' requirements.


"Requirement" is a term of art in system engineering.  Requirements  
exist independently of the notions of the humans involved in a  
project.  Requirements constrain the description of the problem, not  
directly the range of possible solutions that address those  
requirements.  The first phases of any project map onto an adventure  
in the discovery of the project requirements.  Think Indiana Jones.   
Some notional description of a project is handed to an engineer.  The  
engineer begins to speculate on the "concept of operations".  "Use  
cases" are described (typically ad hoc user scenarios at this point).   
The use cases start to reveal requirements.  The point is that the  
requirements exist in the Platonic ideal of the project, they are not  
imposed by external agencies.

It is certainly true that many timekeeping applications do not require  
high precision.  I will not rehash here all the years of prior  
discussions on this list - however, a leap second is a mechanism for  
tweaking the rate of a clock, not just a one-time offset.  Pretending  
UTC doesn't have leap seconds is an inappropriate misuse of project  
requirements.

Rather, a project should recognize that it has dependencies on civil  
timekeeping standards and infrastructure, that these depend on UTC in  
particular, and that UTC has something called leap seconds.  What the  
project is going to do about this simple fact of the existence of a  
project requirement (among hundreds or thousands of other  
requirements) is something for the project management and engineering  
to consider.  Simply pretending the requirement doesn't exist is not  
one of the options.

Perhaps a project might issue a lien against the requirements.  A lien  
doesn't say "we will ignore this requirement", a lien says "we  
recognize this requirement, but for the reasons listed below will not  
pursue any of the options listed for addressing the requirement - the  
resulting implications are here".  The point is that failing to  
address a requirement has implications - precisely because the  
requirement exists independently of the opinions of the stakeholders.   
Are the implications acceptable?  A matter of debate in each case, but  
that debate is made possible only after revealing the existence of the  
issue in question.

For many "consumer" level projects, the "large tolerance for errors"  
that has been mentioned time and again over the years is really  
something else.  It is a *lack* of tight tolerances for the logistics  
of using the system or application in question.  For instance, many PC  
packages can ignore leap second issues (usually) because there is an  
implicit assumption that the PC will be frequently rebooted and the  
clock will be reset.

Intuition is pointless if it doesn't map onto physical (or  
conventional as Steve says) reality.  My freshman physics professor  
told us that our goal that year was to "articulate our intuitions".   
(The Dean said "tedium and solitude are the inseparable companions of  
scholarship" :-)

Rob