[LEAPSECS] Crunching Bulletin B numbers

[Rob Seaman]

Warner Losh wrote:


> Applying the short-term models that work really well for 500 days (that result in an error bar of about 100ms) to long-term works adequately well for most people, but would exceed the 1s tolerance in the 1000-1500 day time frame due to the list of factors that you've listed.


What I found interesting about the exercise was:

	1) Multiple teams using different methods appear to significantly beat 100ms over 500 days.

	2) Archival data could be used to expand the experiment to multiple epochs and to longer-term predictions.

	3) It appears that nobody has actually conducted a longer term exercise.  Is it 1s / 1500 days?  Or worse...or perhaps even significantly better than that?

	4) The EOP PCC demonstrated a willingness to consider predicting UT1 separate from the other EOP numbers.  A simple model might well be sufficient for the purpose of scheduling leap seconds.


> That's part of the compromise that I've put forward.  Goal: publish them out 10-20 years.  To get to that goal we can do things like let it get to 1.1s and see what breaks as Tom has suggested.  We can provisionally publish things out one, two or even three years at first until the models improve.  Based on experiences of purposely pushing things past the edge, as well as doing things out a few years, we can gradually stretch that time horizon.


Sounds like an eminently practical compromise.  This is a multi-sided issue, but if we simplify by characterizing only two sides, "pro" and "con" leap seconds, then neither side might find this compromise ideal - but also, neither side is going to find it unacceptable relative to the status quo.  More to the point, we can later adjust the scheduling to shift the compromise more aggressively one way or the other.  This is a prudent, low risk exercise.


> 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.


Possibly.  This is a good area of study.  The study can proceed incrementally by stages.


> which would give us a leap second every 18 months, starting June 2012.  Of course, we'd have to tweak the frequency every century to (a) steer to 0s off and (b) track the observed LOD trends (or in other words, to steer in phase and frequency to keep UTC synchronized to UT).


Note other possible variations here:

	1) If the bounds on DUT1 are relaxed "a skosh", the extra scheduling slack could be used to limit leap seconds to only December, that is, eliminate June leap seconds.

	2) As a result, the IERS leap second workflow would occur only annually (as a sliding window N years in the future) instead of twice a year.

	3) We could immediately (like today) and *without the participation of governments worldwide* extend the horizon to - say - two years.  Just crunch the numbers and announce yea or nay on leap seconds for Dec 2011 and Dec 2012.  A quick look at the last few Bull-D's (http://bit.ly/gTrbaE) suggest a high likelihood of Yea for Dec 2011 and Nay for Dec 2012.

	4) By the end of 2011, the IERS would announce yea-or-nay on a leap second for Dec 2013.  (Currently looks like a toss-up, but almost certainly within the 0.9s bounds to say "Yea".)

	5) As the models are improved or the understanding and consensus grows of the scheduling trade-offs, additional years could be added to the horizon.  Perhaps by the end of 2012, Gambis could announce all leap seconds through Dec 2015.

	6) At some point we would understand enough to relax the 0.9s limit on DUT1.  Perhaps this would be immediately, perhaps in a few years - in any event it could easily occur *before* 2018.  This is a way to accelerate adoption of the changes *faster than the ITU* could manage.

	7) Additional slack could be used to simplify it a little more.  Perhaps preferred leap seconds opportunities for the next decade could be limited to odd/even year boundaries, not even/odd.  Or perhaps the slack would be used to extend the horizon.

	8) We could simultaneously be discussing improvements to the DUT1 alert messaging.  This has interesting parallels with work on celestial transient alert protocols (http://voevent.org), for instance.

	9) ...And we could simultaneously be discussing a complete revamp to civil timekeeping, reaching consensus before planning action.

	10) What worlds of possibilities there are if the ITU can be persuaded to avoid the train wreck they're about to cause!


> If we had something like that, then leap second compliance would approach that of leap-day compliance in modern software.


I think this is an accurate statement.

I see Ian and PHK have replied with similar points.  Anybody at the IERS listening?

Rob