[LEAPSECS] The man in the moon's too slow

[Rob Seaman]

On Jan 23, 2015, at 5:33 AM, Steffen Nurpmeso <sdaoden at yandex.com> wrote:

> Rob Seaman <seaman at noao.edu> wrote:
>> It is much cleaner and more robust to support the entire history of leap seconds.
> 
> Ok i'll bite: why this?  This service would only track future changes with the first adjustment happening at 2015-06-30.

You are presuming a narrow (and so far unstated) concept of operations.  We know there are retroactive use cases for UTC timekeeping and thus for leap seconds.  Other methods and services may certainly be used to address those, but there is no strong reason to limit the design of a new service to make support impossible.  Also, by truncating support for a standard at an arbitrary point sometime other than when the standard took effect confusion becomes more likely among users or implementers.  Leap seconds began in 1972; the encoding should start in 1972.

>> The longer the string of positive leap seconds go on, the harder it will be to force it negative in any physically realistic way.
> 
> This is logical.  I indeed have *no* idea on what can happen, which is one of the reasons that i am on this list, because so many specialists from many different specialist fields can (or could) show up.  For example i didn't know that even snow storms have a measurable effect on earth rotation.

It's a question of scale.  A snow storm (even Snowpiercer) will not trigger a negative leap second.  Maybe if you ran the Snowpiercer train in reverse?

> Does anyone really know what this will mean on the long run.

Morrison and Stephenson: http://ucolick.org/~sla/leapsecs/ancient.pdf

Before a few hundred BCE, the divergence of LOD from 86400 SI-seconds was too large to be accommodated by ITU-R TF.460, i.e., it would have required more than one leap second per month.  For a thousand years from Aristarchus to Brahmagupta, there would have been around one a month; by the time of Abū Rayḥān al-Bīrūnī a comfortable oversampling was possible. As the Moon recedes the Earth will continue to slow (http://www.xkcd.com/1441/); Nyquist and Shannon will continue to hold sway until Jacob Buckman gets a peek around the far side of the Coalsack.

For a couple of centuries around the time of Hypatia the Earth's slowing appears to have paused and LOD decreased by a couple of milliseconds.  If this happened now it could cause a long series of negative leap seconds - or not - depending on the precise details of integrating under the curve.  As of July this year there will be an accumulation of +36s to overcome, which is precisely 1/50 of the half-hour color swatches on Steve Allen's diagram.  Recent downward dips in the 17th and 19th centuries don't appear to reach that level.  Undoubtedly the M&S data smooth over larger short term excursions, but "short term" here implies many decades of notice.

>> Bulletin C is issued whether or not a leap second occasion (currently June and December, but could be any month) corresponds to an actual leap second.  The encoding (as in PHK’s example) should be able to represent a positive, negative or absent leap second.
> 
> That doesn't make sense to me.  An absent leap second doesn't change the TAI-UTC drift, so why would you update the record?

	http://datacenter.iers.org/eop/-/somos/5Rgv/getTX/16/bulletinc-048.txt

> So in order to calculate the actual date where the drift adjustment occurs you have to face
> a very elaborate conversion.  With two more bits for the day the calculation could be performed when creating the record, permitting simplemost scripts/programs to display the correct date and time of the actual leap second by only decoding the DNS information.

Even if provided an explicit ISO-8601 date/time stamp an application still needs to know Gregory's rules to interpret it.  Display isn't the only use case.  "End of the month" best corresponds to the letter and intent of TF.460.

Rob
--
What's past is prologue, what to come
In yours and my discharge.