RR? > On Jan 23, 2015, at 2:43 PM, Steffen Nurpmeso <sdao...@yandex.com> wrote: > > Rob Seaman <sea...@noao.edu> wrote: > |On Jan 23, 2015, at 5:33 AM, Steffen Nurpmeso <sdao...@yandex.com> wrote: > > |> 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? > > I haven't seen that film. (And i don't think i will.) > In Thailand they have tried for many years to inject -- was it > silver iodide -- to gain rain where they need it. > > |> Does anyone really know what this will mean on the long run. > | > |Morrison and Stephenson: http://ucolick.org/~sla/leapsecs/ancient.pdf > > I'll read what follows, but i referred to what'd happen if the > slowdown / speedup what happen in the few decades that the RR can > eventually live. > > --steffen > > From: Rob Seaman <sea...@noao.edu> > Date: January 23, 2015 at 8:08:28 AM MST > To: Leap Second Discussion List <leapsecs@leapsecond.com> > Subject: [LEAPSECS] The man in the moon's too slow > Reply-To: Leap Second Discussion List <leapsecs@leapsecond.com> > > > On Jan 23, 2015, at 5:33 AM, Steffen Nurpmeso <sdao...@yandex.com> wrote: > >> Rob Seaman <sea...@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. > > _______________________________________________ > LEAPSECS mailing list > LEAPSECS@leapsecond.com > https://pairlist6.pair.net/mailman/listinfo/leapsecs > > > _______________________________________________ > LEAPSECS mailing list > LEAPSECS@leapsecond.com > https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
