[LEAPSECS] The relation between Easter and leap econds.

[Rob Seaman]

This is an excellent example of how focusing on the requirements  
(rather than notional solutions) helps to clarify the discussion.  For  
one thing, the issue becomes one of describing the problem before  
trying to figure out what to do about.  For another, the discussion is  
abstracted from entrenched positions.  For a third, we start to reveal  
underlying points of agreement (eg., disdain for politicized issues),  
not just differences.  And for a fourth, the process finds a natural  
pace.  If there are important scheduling drivers, what are they?  In  
short, what is the hurry?

Regarding the specific points here:

1) Yes, indeed!  Requirements change.  This is all the more reason to  
focus on characterizing them now, and as they evolve.  How else to  
figure out what's going on?

2) Describing the process is separate (although entangled) from  
describing the problem.  I could wish some other process were being  
followed, most obviously that whatever standards body this drama is  
played out in, the deliberations should be open.

3) Virtually all system engineering is for the benefit of users who  
are non-experts.  This does not distinguish timekeeping in any special  
way.  What users want and what they need are often very different.   
They may not care (or think they care - or even be aware) about time,  
but that doesn't mean timekeeping doesn't enter the user requirements  
in numerous ways.

4) A large project will have a long list of requirements.  Timekeeping  
is deceptively simple.  Stepping aside from solar time for a moment,  
just think of the very complex system of systems that generates and  
delivers interval time, whether "atomic" or GPS.  Ensembles of very  
complex clocks.  Multiple interlocking strata of NTP servers.  Host OS  
support.  (Bad solutions are likely to be even more complex than good  
ones :-)  Etc and so forth.

5) Elected government officials are already involved.  They changed  
DST last year (and not just in the U.S.)  The ITU is an assemblage of  
government representatives, only by happenstance are they scientists.

6) To focus on the requirement at hand for a moment:  Pete Bunclark's  
comment about "a single monotonic calendar" points out that we already  
have this situation.  A mean solar clock is a subdivision of the  
calendar.  Modifying UTC to eliminate leap seconds would violate this  
requirement.  It is better to state and debate - and yes, perhaps  
reject - the requirement, than it is to leave the requirement hidden  
and violate it for some imagined short term political expediency.

6a) Why?  Because if the requirements aren't stated, then engineers  
and decision-makers creating contingent systems (and there are many,  
many systems contingent on timekeeping) can draw diverse - and  
diversely wrong - conclusions about the behavior of time.  This is  
precisely the situation decried now with leap seconds.

6b) It is not sufficient to describe a solution.  If the problem that  
a system or standard is intended to solve is left poorly described,  
stakeholders won't comprehend the context to apply it appropriately  
across all (or perhaps any) situations.  Again - see leap seconds.  A  
hasty elimination of leap seconds will leave them as the proverbial  
dog that didn't bark - not present, but not absent either.

7) Requirements are not demands from stakeholders (although  
stakeholders make lots of - often incoherent - demands :-)  Rather,  
proper requirements form a coherent and self-consistent set of  
descriptors of the problem and project at hand.  Think of them as an  
orthogonal set of basis vectors in a multidimensional parameter space  
that captures the essence of the problem and supplies constraints on  
the acceptable solutions.

Rob Seaman
NOAO
---

Poul-Henning Kamp wrote:


> Tony Finch writes:

>

>> My point is that user requirements change. The relation between  

>> natural

>> phenomena and our consensus idea of time depends on how accurately  

>> and

>> quickly we can measure those phenomena, and which phenomena we care  

>> about

>> tracking.

>

> Couldn't the opposite argument be made:  The majority of users don't  

> care

> a hoot about time (ref: flashing 12:00 everywhere) and therefore the

> scientists and engineers who have to care, are free to implement

> any working solution ?

>

> After all, with the cavalier attitude politicians have to time, (ref

> timezone changes with short notice, century old laws etc), I can't

> see any good coming out of involving them.

>

> In other words: WP7A may not be the best place, but it is probably

> as good as any.