[LEAPSECS] Crunching Bulletin B numbers

[Warner Losh]

On 02/18/2011 13:05, Ian Batten wrote:

>>

>> Given that we know approximately what the end point will be 100 years 

>> from now, we could even have a mechanical rule like the leap-day rule 

>> that would put us in the right neighborhood of synchronization.  

>> Having a good, formulaic/mechanical method for declaring leap seconds 

>> would be a vast improvement over the 'update your tables every 6 

>> months' we see today.

>>

>> I'd bet that the following would keep us within 10s over the next 100 

>> years:

>>

>> bool

>> leap_second_end_of(int year, int month)

>> {

>> int m = (year - 2012) * 12 + month - 6;    /* First leap june 2012 */

>

> If the idea is a low-risk, low-complexity holding action to see what 

> happens, starting that with a June leap-second seems a bad idea; there 

> hasn't been once since 1997, so there's probably more uncertainty 

> about procedures and code than there would be for December.  Indeed, 

> if you're going to have a mechanistic formula to arrive at 

> ~6.5s/decade, something like "leap Dec31 in every year that isn't 

> divisible by 3" would be about the same long-term and have the merit 

> that it always takes place at the same time of year when most, not all 

> but most, economies are in a holiday season.


I'm all for tweaking the formula to make sense.  I'd thought that having 
a June leap second wouldn't present a problem to most folks.  However, 
having a leap second 2 out of 3 years would give us 67 leap seconds in 
the next century.  My formula would have given a similar number and been 
more regular, but did have regular June leap seconds in the mix.

I'm agnostic on any tweaks to the formula for operational considerations 
like this.  Given the LOD trends, does this give enough leap seconds 
over 100 years to try to put forward as a useful compromise?

Warner


>

> ian

> _______________________________________________

> LEAPSECS mailing list

> LEAPSECS at leapsecond.com

> http://six.pairlist.net/mailman/listinfo/leapsecs

>

>

>