[LEAPSECS] The relation between calendars and leap seconds.

[Rob Seaman]

Tony Finch wrote:


> there's no problem dividing a day into 86400 equal seconds if you  

> can't measure time accurately enough to detect variations in the  

> length of a day.


A single day, no.  An unending sequence of days?  Yes, there is a  
problem - the problem we have.  In addition to Pete's stated  
requirement, or perhaps a corollary, is some sort of requirement on  
the secular rate between the solar timescale and the interval timescale.


> If you need the kind of accuracy you get from atomic time, you  

> cannot satisfy the requirement for equal subdivisions of a day.


Right.  Which is why we're going to continue to find it impossible to  
discover a complete and self-consistent set of requirements that  
pretends there is a single timescale, not two different timescales.


> While we are taking a historical view of calendars, it's probably  

> worth

> observing how past problems similar to the current situation have been

> resolved. UTC is an observational calendar, and over history these  

> have

> almost always been replaced with arithmetic calendars: this eliminates

> problems of communication from the observers who determine the  

> calendar to

> its users, gives users more independence and allows them to make more

> accurate plans for the future, at the cost of a smallish error that  

> makes

> future dates drift away from the events they were previously  

> attached to.


Words like "smallish" are to be avoided when writing requirements.   
Fundamentally your assertion is still that nobody but astronomers will  
notice, right?  So how might this be characterized in specific terms?   
That will give us something to grapple with.

I like your observational/arithmetic formalism - although I might draw  
different conclusions.  The thing about calendars is that the  
observational aspect is quantized - today is today, tomorrow is  
tomorrow.  Underneath the sexagesimal notation (even variable radix),  
a clock is an unending count of tick, tick, ticks.  (To oversimplify,  
days are integers, seconds are reals.)  It is precisely the chunking  
into those inconvenient things called "days" (the mean solar part of  
the situation) that creates our dilemma.


> Calendars get reformed if they are not sufficiently predictable.  

> This is

> happening now to UTC, which seems to be the result of a timeless human

> factors requirement in action.


I'm skeptical, but that's ok.  The way to conquer skepticism in system  
engineering is to refine such points of friction into clear  
requirements, functional or non-functional ("thou shalt" sort of  
statements).  What is this human factors requirement?

Adi Stav wrote:


> On Mon, Nov 10, 2008 at 04:13:25PM +0000, Tony Finch wrote:

>>

>> I agree with your requirements 2,3,4 and I note that UTC doesn't  

>> satisfy

>> 3, which is another statement of this timeless predictability  

>> requirement.

>> (Your requirement 4 is only relatively timeless, since it allows for

>> changes in the definition of the second.)

>

> Have there been suggestions, indeed, for such a predictable SI- 

> second-based

> calendar that synchronizes with the Earth's rotation?



Well, that is the UTC that we have.  Two timescales, earth orientation  
and interval.  Compromise a little on the SI part and a little on the  
solar day part to jigger these two things into a single standard.

I'd be complaining just as loudly if the relentless suggestion over  
the past nine years had been to ratchet the balance the other way and  
completely jettison SI.  (Lest folks think I'm a one note kind of  
guy :-)

However, this is short-circuiting the process to jump to speculating  
on solutions before we've finished describing the problem.  At some  
point we'll have a candidate set of requirements - this doesn't have  
to be finalized, just somewhat complete.  At that point, a trade-off  
study between various solutions - really between classes of solutions  
- can be compiled.  Write down a list of various figures of merit,  
score them for each solution, weight and combine the scores (really  
the scoring functions).  Look at the holy trinity of cost, performance  
and schedule that can be achieved for each option.  Iterate, since the  
first few trade-offs will inevitably reveal additional requirements  
(and perhaps suggest new kinds of solution).  Throw in a sensitivity  
analysis, perhaps.  Look at the risks.  And continue the basic idea of  
arguing about the methodology, not entrenched positions.

Note one strong advantage to such a process.  It enables the  
stakeholders to ignore the various proposed solutions (ie., those  
entrenched positions), while gathering support for the eventual winner  
in an unbiased fashion in the mean time.

Rob Seaman
National Optical Astronomy Observatory