Re: predicting leap seconds
In message: <[EMAIL PROTECTED]> Neal McBurnett <[EMAIL PROTECTED]> writes: : I still haven't seen any good data on predictions for periods of : longer than 9 years. Neal, thanks for the excellent summary of the current state of the art in prediction. I think this shows that a 20 year time line is unrealistic at this point, but 5-10 years would keep things fairly close, and 4 years should be able to keep the current tolerances. It might be worth an experiment where over the next 5 years IERS publish 12 new months of data every 6 months. (eg Jan 2006 publish both the June 2006 and Dec 2006 correct, July 2006 publish the June 2007 and Dec 2007 correction, Jan 2007 publish Jun 2008 and Dec 2008). We'd hit 4 years in advance in Jan 2009. This would phase in the predictive timeline for leap second insertions, and would also give the IERS control to end the experiment if the time horizons exceeded their ability to predict with confidence. This would be an evolutionary step, rather than a revolutionary one. Of course this would make them even more entrenched than they already are, because to kill them would require waiting many years... Warner
Re: The real problem with leap seconds
Ed Davies <[EMAIL PROTECTED]> wrote: > UTC is expressible as a real number in just the same way that > Gregorian dates (with months with different lengths and leap > days) can be with the Julian calendar. > > There's no difference in principle between converting from a > TAI time in seconds since some epoch to a UTC date/time in > days, hours, minutes, seconds and fractions of a second [...] You have dodged the problem so conveniently! Of course I know how to convert UTC to TAI or vice-versa, but that is not the problem statement at hand. The problem statement at hand is to express UTC *itself* as a real number, rather than convert it to some other time scale. For UTC itself must be expressible as a real number in order to be called a time *scale*. If you admit that this cannot be done, then you should revise TF.460-6 to remove all use of the word "scale" and openly admit to UTC being a time non-scale. Then no one will use UTC as the civil time scale since it'll be obvious that as a non-scale it is not suitable as a scale of any kind. I stand by my assertion that the current ITU-R spec for UTC (and its previous CCIR versions) is a clever scam, a parlor trick designed to sell a non-scale to civil philosophers wanting a SCALE of civil time. The manner in which it was adopted in 1970 by CCIR, a shove-down-the- throat move reminiscent of the current leap hour scheme, does not help them look any better. MS
Re: The real problem with leap seconds
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > In this rather humorous document you have managed to say that POSIX > screwed up badly. We already knew that :-) What does this have to do with POSIX? The word POSIX does not appear in my article. MS
Re: The real problem with leap seconds
Steve Allen <[EMAIL PROTECTED]> wrote: > If I read it right you have reinvented Markus Kuhn's UTS [...] Close to it, but... Ed Davies <[EMAIL PROTECTED]> followed up: > Also, Markus wasn't proposing UTS as a civil timescale but just > for use within computer systems, etc. Therein lies the key difference. I have strived to make my argument as independent of computers as I could. To me the need for a real number time scale is necessitated more by philosophy than computer science, which is why I have resorted so much to the mathematical abstraction of a real number in my paper. My central argument still stands that current UTC is unsuitable for the *philosophical* application of defining the abstract ideal scale of civil time since it is not a scale in the mathematical definition of this term (a real number). I believe that the scale of civil time needs to be a scale. Furthermore, I believe that it should be related to the cycle of day and night rather than completely decoupled from it, so I won't support freezing the leap seconds for the next few centuries as a "solution". That leaves me with my current position of arguing for a coordinated time scale with elongated and shortened seconds. MS
Re: The real problem with leap seconds
Please ignore this post. It got away because I was connected to my UNIX host from my girlfriend's PC over her cable Internet connection which is probably the crappiest in the world as I was composing a reply to some posts on this list, and as it crapped out on me, the mail process on the UNIX host terminated and sent out whatever garbage was in its compose buffer. MS
Re: The real problem with leap seconds
>From [EMAIL PROTECTED] Sat Jan 7 08:03:04 2006 Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by ivan.Harhan.ORG (5.61.1.3/1.36) id AA14507; Sat, 7 Jan 06 08:03:03 GMT Received: from rom.usno.navy.mil by [198.116.61.253] via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006 08:10:46 UT Received: from ROM (rom.usno.navy.mil [10.1.4.27]) by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k077o0kU019926; Sat, 7 Jan 2006 08:02:52 GMT Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release 1.8e) with spool id 0549 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 08:02:52 + Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k0782pkM019980 for ; Sat, 7 Jan 2006 08:02:52 GMT Received: from santo.ucolick.org ([128.114.23.204]) by TS-FW.usno.navy.mil via smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006 08:10:36 UT Received: from localhost (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 475575D715 for ; Sat, 7 Jan 2006 00:02:51 -0800 (PST) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id D9F7C11419 for ; Sat, 7 Jan 2006 00:02:50 -0800 (PST) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (8.13.1/8.12.10) with ESMTP id k0782ofC025400 for ; Sat, 7 Jan 2006 00:02:50 -0800 Received: (from [EMAIL PROTECTED]) by geneva.ucolick.org (8.13.1/8.13.1/Submit) id k0782oFP025399 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:50 -0800 Date: Sat, 7 Jan 2006 00:02:50 -0800 From: Steve Allen <[EMAIL PROTECTED]> To: Leap Second Discussion List Subject: Re: The real problem with leap seconds Message-Id: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <[EMAIL PROTECTED]> User-Agent: Mutt/1.4.2.1i Sender: [EMAIL PROTECTED] Precedence: list Status: RO On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ: > http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt If I read it right you have reinvented Markus Kuhn's UTS as seen in http://www.cl.cam.ac.uk/~mgk25/uts.txt http://www.cl.cam.ac.uk/~mgk25/time/leap/ http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf -- Steve Allen <[EMAIL PROTECTED]>WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m >From [EMAIL PROTECTED] Sat Jan 7 12:28:40 2006 Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by ivan.Harhan.ORG (5.61.1.3/1.36) id AA14637; Sat, 7 Jan 06 12:28:38 GMT Received: from rom.usno.navy.mil by [198.116.61.253] via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006 12:36:23 UT Received: from ROM (rom.usno.navy.mil [10.1.4.27]) by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k07BLaki031306; Sat, 7 Jan 2006 12:28:29 GMT Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release 1.8e) with spool id 0583 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 12:28:28 + Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k07CSRkM032500 for ; Sat, 7 Jan 2006 12:28:28 GMT Received: from mail.metronet.co.uk ([213.162.97.75]) by TS-FW.usno.navy.mil via smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006 12:36:12 UT Received: from [192.168.26.3] (213-162-103-78.edmund434.adsl.metronet.co.uk [213.162.103.78]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id 72B0F408240 for ; Sat, 7 Jan 2006 12:28:18 + (GMT) Message-Id: <[EMAIL PROTECTED]> Date: Sat, 07 Jan 2006 12:28:20 + From: Ed Davies <[EMAIL PROTECTED]> User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en Mime-Version: 1.0 To: Leap Seconds Issues Subject: Re: [LEAPSECS] The real problem with leap seconds References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: [EMAIL PROTECTED] Precedence: list Status: RO Steve Allen wrote: > On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ: > > >>http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt > > > If I read it right you have reinvented Mark
predicting leap seconds (was Re: [LEAPSECS] Where the responsibility lies)
On Wed, Jan 04, 2006 at 07:36:17AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Neal McBurnett writes: > >On Tue, Jan 03, 2006 at 08:32:08PM +0100, Poul-Henning Kamp wrote: > >> If we can increase the tolerance to 10sec, IERS can give us the > >> leapseconds with 20 years notice and only the minority of computers > >> that survive longer than that would need to update the factory > >> installed table of leapseconds. > > > >Do you have any evidence for this assertion? > > It is an educated guess. > > The IERS have already indicated that they belive they could do prediction > under the 0.9 second tolerance with two or three year horizon. The Torino Colloquium had some discussion of this. Proceedings of the Colloquium on the UTC Timescale held by ITU-R SRG 7A http://www.ien.it/luc/cesio/itu/ITU.shtml Prediction of Universal Time and LOD Variation D. Gambis and C. Bizouard, (IERS) http://www.ien.it/luc/cesio/itu/gambis.pdf After a bunch of nice graphs (not all of which were easy to interpret) I found the periodogram (essentially a discrete Fourier transform of the input data) interesting. The way I read it (expert advice welcomed), the broad peaks at 26 years (0.6 ms/d) and 52 years (0.3 ms/d) suggest that the most common pattern is a gradual cycle a few decades long of lengthening and shortening of the day, presumably driven by movements in the earth's mantle and core. Page 14 of the pdf has a table: Skill of the UT1 prediction statistics over 1963-2003 Horizon Prediction accuracy in ms 3 years 308 2 years 163 1 year 68 180 days 36 90 days21 30 days 7 10 days 3 Perhaps these are worst cases? It would be nice to have confidence intervals. They presented these conclusions: Possibility to predict UT1 with a 1s accuracy at least over 4 years using a simple method : seasonal, bias and drift. New prediction methods are under investigation (Singular Spectrum Analysis, neural network,..) Possibility to use Core Angular Momentum prediction for decadal modeling Steve Allen wrote: > http://www.ucolick.org/~sla/leapsecs/McCarthy.html > > This deserves discussion and analysis and explanation. I wrote Dennis McCarthy about that, and he said he'd look up the details and get back to me next week. But he did remind me of this, which I remember seeing in data they published via ftp years ago: > Regarding the accuracy of these long-term predictions, the IERS > Rapid Service and Prediction Center located at the U. S. Naval > Observatory does make predictions of Delta-T in the IERS Annual > Report. The algorithm for those predictions was determined > empirically by testing a wide range of possibilities. It is > essentially an auto-regressive model using the past ten years of > data. The accuracy based on comparison of observations with what > would have been predicted using that model is shown in the table > below. Note that the accuracy estimates are 1-sigma estimates and > that excursions of 2-sigma (or more) may not be unexpected. > > +-+ > |Year in the Future|Accuracy (1s) (seconds| > |--+--| > |1 | .04 | > |--+--| > |2 | .08 | > |--+--| > |3 | .3 | > |--+--| > |4 | .8 | > |--+--| > |5 | 1. | > |--+--| > |6 | 2. | > |--+--| > |7 | 2. | > |--+--| > |8 | 3. | > |--+--| > |9 | 4. | > +-+ The http://www.iers.org/ points eventually to http://141.74.1.36/MainDisp.csl?pid=47-25786 but the links from there to the annual reports seem broken right now. I still haven't seen any good data on predictions for periods of longer than 9 years. Neal McBurnett http://bcn.boulder.co.us/~neal/
Re: The opportunity of leap seconds
On Jan 7, 2006, at 11:37 AM, John Cowan wrote:Whether we choose to bleed off the daily accumulating milliseconds one second or 3600 at a time, bleed them we must...and even people who loathe the very notion of leap seconds admit this. NO, I DON'T ADMIT THAT. On the contrary, I deny it, flatly, roundly, and absolutely.Alternately, you could read what I said. I wasn't claiming all such people would admit it (though, of course, they should). I was pointing out that the ITU already felt obligated to admit it.We've long since devolved into a Monty Python sketch: Owner: Well, o'course it was nailed there! If I hadn't nailed that bird down, it would have nuzzled up to those bars, bent 'em apart with its beak, and VOOM! Feeweeweewee! Mr. Praline: "VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised! Owner: No no! 'E's pining! Mr. Praline: 'E's not pinin'! 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!! THIS IS AN EX-PARROT!The leap-hour proposal can be read as either (a) a serious proposal to inject an hour into UTC at some future date, or (b) a cynical proposal to abandon leap seconds and not replace them.I think (a) is just as foolish as leap seconds, if not more so.Glad to hear you say it.The computerniks of the world already know how to handle such things, so future migrations will not be a problem.Thanks! I needed a good chuckle :-)
Re: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Steve Allen writes: >On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: >> You can find locate your countrys ITU-R representative and contact >> them with your input, just as well as I can for mine. > >You can try that, and you may succeed, but it is deceptive to assert >that is easy to do. As far as I know, pretty much anybody can get observer status in the working group for a modest/outrageous (take your pick) amount of money. >> There is nothing hidden, undemocratic or revolutionary about it. >> The ITU _process_ does actually work. > >Agreed, you just have to be prepared to play the Byzantine games. Well, that's politics for you. Just because one doesn't like the rules doesn't mean that they're not fair. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: > You can find locate your countrys ITU-R representative and contact > them with your input, just as well as I can for mine. You can try that, and you may succeed, but it is deceptive to assert that is easy to do. In the US the process is Byzantine. Whereas it is apparently required that draft contributions to the ITU be publicly available, it is apparently not required that their availability be published outside of predefined special interest groups. I would describe more of what I know, but given that my knowledge is assembled from little bits gleaned from unrelated documents I'm not convinced I am right. If anyone else cared to challenge me to post the rules of some other nation I'll gladly rise to the challenge and post the US rules. > There is nothing hidden, undemocratic or revolutionary about it. > The ITU _process_ does actually work. Agreed, you just have to be prepared to play the Byzantine games. -- Steve Allen <[EMAIL PROTECTED]>WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: The real problem with leap seconds
In message: <[EMAIL PROTECTED]> "Daniel R. Tobias" <[EMAIL PROTECTED]> writes: : On 7 Jan 2006 at 16:02, Poul-Henning Kamp wrote: : : > Civil time is in the hands of individual governments, and they : > tend to expect their computers to use the same time as the : > rest of their country. : : And, in many countries (including the United States), the legally- : defined civil time is the mean solar time at some particular spot, or : a fixed or seasonally-variable offset from it. Any use of UTC-based : time scales for determining civil time in such places is merely an : approximation, currently to within a second, but perhaps varying by : greater amounts if some new timekeeping plan is adopted. Once UTC : stopped being a sufficiently-close approximation to the solar mean : time at the Prime Meridian (with "sufficiently close" possibly being : of differing values depending on the particular purpose), it would be : necessary to either stop using UTC for determining civil time in such : countries, or to change the law to base the civil time on UTC instead : of a solar standard. The US's legislation leaves it to the commerce department to define what the mean solar time is (or rather states that it is the mean solar time, as determined by the secretary of commerce). This is what presumably gives us leap seconds and the like in our civil time and when we insert them. This is a political function: Up to a second of tolerance is allowed and leap seconds are inserted whenever everybody else does. The same political decision could be made to say something else, since it is the folks in DC could say that a minute is close enough to solar mean and that's what we're going to do. Warner
Re: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Neal McBurnett writes: >> Civil time is in the hands of individual governments, and they >> tend to expect their computers to use the same time as the >> rest of their country. > >Yes again. And they are free to choose TAI if they want a uniform >time scale. But why take the choice of a UTC that remains within 0.9s >of the earth's average rotation rate? Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can see where he is coming from on that one. The snippy answer to why UTC was adopted for civil timekeeping would be "Because they got bad advice", but that would be grossly unfair since nobody (but possibly Dave Mills) at that time could be expected to foresee what computer networks would result in and how that would affect the needs for timekeeping. Just like the variable rate atoms of the sixties where a bad idea we now know that the variable length days that replaced them are bad. I'm not old enough to have any axe to grind about the last couple of redefinitions of time, but I can see where they both went wrong (insisting on using the unprecise and unstable clock to discipline the stable and precise clock) and I want us to stop that mistake. >Here we disagree. I guess you're confirming what is in fact the >current problem as I see it. We're here because an ITU committee, >shrouded in secrecy, is trying to redefine UTC and the international >distribution of time signals, which most jurisdictions rely on one way >or another as civil time. But you overlook that ITU is an international organization under the UN aegis. If ITU in their plenary assembly decides to do something, no matter how stupid, (X.400 for example), that is nontheless the will of the governments of the world. You can find locate your countrys ITU-R representative and contact them with your input, just as well as I can for mine. There is nothing hidden, undemocratic or revolutionary about it. The ITU _process_ does actually work. I will agree that a lot of what ITU churns out, UTC with leapseconds and X.400 being my best examples, are rubbish. >Some folks here suggest that legislatures just change their timezones >periodically, forced by the actions of the ITU. But data was >presented in Torino suggesting a cost to NASA and US DoD of a half a >billion dollars to study, re-engineer and test their systems if UTC >diverges markedly from UT1. Not an easy thing for a legislature to >deal with. Again - it's a process problem Let me channel something that gets said a lot here: "They should have used the right timescale from the beginning". It sounds like they should have used UT1, doesn't it ? And why is it that IT related costs matter so much if they come from people worried about the effect of lack of leapseconds, while at the same time, they don't matter at all if they come from people worried about the effect of leapseconds ? Clearly what's good for the goose is good for the gander, right ? >The only time there has been an inclulsive international meeting >devoted to the issue, at the colloquium in Torino, "There was no >overwhelming consensus on whether the status quo should be maintained >or an alternative should be pursued." ... at that meeting. The only consensus that matters is the ITU-R SG7A, which coincidentally didn't reach one either. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
On 7 Jan 2006 at 16:02, Poul-Henning Kamp wrote: > Civil time is in the hands of individual governments, and they > tend to expect their computers to use the same time as the > rest of their country. And, in many countries (including the United States), the legally- defined civil time is the mean solar time at some particular spot, or a fixed or seasonally-variable offset from it. Any use of UTC-based time scales for determining civil time in such places is merely an approximation, currently to within a second, but perhaps varying by greater amounts if some new timekeeping plan is adopted. Once UTC stopped being a sufficiently-close approximation to the solar mean time at the Prime Meridian (with "sufficiently close" possibly being of differing values depending on the particular purpose), it would be necessary to either stop using UTC for determining civil time in such countries, or to change the law to base the civil time on UTC instead of a solar standard. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/
Re: The real problem with leap seconds
On Sat, Jan 07, 2006 at 04:02:04PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Ed Davies writes: > >Ignoring the ridiculous parody - no, it's not a weird concept. > >Different timescales are useful for different purposes. Get > >used to it. > > I have no problems with different timescales for different purposes. > > For instance I very much wish the Astronomers would start to use > UT1, which is very much "their" timescale, and stop abusing UTC, > which isn't, as a "convenient approximation". > > But I have big problems with people who want to introduce more > timescales without thinking through the legal and technical > complications. Yes And with people that want to redefine existing time scales so they mean one thing in one era, and another thing in a different era. As happened with GMT, or the proposed changes to UTC. > >The question is, where in the range of possible timescales is > >it most useful to put civil time. > > Civil time is in the hands of individual governments, and they > tend to expect their computers to use the same time as the > rest of their country. Yes again. And they are free to choose TAI if they want a uniform time scale. But why take the choice of a UTC that remains within 0.9s of the earth's average rotation rate? > Nobody here is in any position to do anything about civil time > or legal time, neither are we in a position to introduce a > "computer time scale" in a pathetic attempt to paste over leap > seconds. Here we disagree. I guess you're confirming what is in fact the current problem as I see it. We're here because an ITU committee, shrouded in secrecy, is trying to redefine UTC and the international distribution of time signals, which most jurisdictions rely on one way or another as civil time. But the way the ITU works undermines the sort of open and informed discussion that is necessary for an issue so sweeping in its legal, practical and philosophical implications. The thing that is most flawed here is the process. > We can talk about _representation_ of a given timescale in computers, > but there are far too many laws to rewrite if we want to dictate > which timescale they should use. But it is inappropriate for ITU to do an end-run around the laws, and redefine the timescale so that it swings an extra hour back and forth. Some folks here suggest that legislatures just change their timezones periodically, forced by the actions of the ITU. But data was presented in Torino suggesting a cost to NASA and US DoD of a half a billion dollars to study, re-engineer and test their systems if UTC diverges markedly from UT1. Not an easy thing for a legislature to deal with. Again - it's a process problem The only time there has been an inclulsive international meeting devoted to the issue, at the colloquium in Torino, "There was no overwhelming consensus on whether the status quo should be maintained or an alternative should be pursued." But "If a change were to be made one alternative appeared to be preferred. The essence of this alternative was as follows: 1. Any change should slowly evolve from the current UTC Standard in transitioning to a uniform timescale, perhaps to be called Temps International (TI). 2. A suggested date for inaugurating any change would be 2022, the 50 TH anniversary of the UTC timescale. The date suggested is influenced by the lifetimes of existing systems that would be expensive to change." [http://www.ien.it/luc/cesio/itu/annex_a.pdf] So it is distressing to see committee members of the ITU headed in a different direction. Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60 > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence.
Re: The opportunity of leap seconds
Poul-Henning Kamp scripsit: > >By your logic, the U.S. Surgeon General should be a chiropractor. > > Once the US government tries to shoulder their national deficit > that would undoubtedly be a good idea. Chiropractors are by no means cheaper to hire than other doctors. Nor are their treatments necessarily the worse because their theory is crappy. > Light of day and darkness of night already is, and for all relevant > future can be, assured by governmental adjustments of the two functions > government control in the formula: > > Civil Time(time) = UTC(time) + > TimeZoneOffset(country, subdivision, time) + > SeasonalOffset(country, subdivision, time) Indeed. I did a quick look once at the number of secular changes to the TimeZoneOffset function since the adoption of standard time in the various countries; I may have posted the results here. If not, I'll try to dig them up. -- John Cowan [EMAIL PROTECTED] www.reutershealth.com www.ccil.org/~cowan There was an old manSaid with a laugh, "I From Peru, whose lim'ricks all Cut them in half, the pay is Look'd like haiku. He Much better for two." --Emmet O'Brien
Re: The real problem with leap seconds
Steve Allen scripsit: > The changes in the length of any kind of year are slight by comparison > to the changes in length of day. Neglecting "short" period variations > the length of the sidereal year has not changed much in a billion years. That is to say, the current best approximation to the n-body problem of the Solar System says that it hasn't. Fair enough. I merely threw that in in case it was an issue. > The Gregorian calendar was designed to match the "vernal equinox year". Thanks for the correction. > The new fields being added to GPS signals make them able to count leap > seconds for 3 years. That's quite an example of engineering margin. Indeed. But then so is IPv6 (if we ever get it adopted widely). -- John Cowan [EMAIL PROTECTED] www.ccil.org/~cowan www.reutershealth.com In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton
Re: The opportunity of leap seconds
Rob Seaman scripsit: > Unless we *completely* change our notion of Canoli, Canoli is tightly > constrained to follow Eclair simply by the fact that today and > tomorrow and the million days that follow are all required to be dark > at night and light in the day. I think you are getting carried away by your own rhetoric here. It will be dark at night and light in the daytime even if we smash every clock on Earth (not a bad idea, I think sometimes). What you surely mean is that it should be locally dark when local clocks say and thereabouts, and consequently light when they say 1200 and thereabouts. There is much room for adjustment around the midpoints, however. > Whether we choose to bleed off the > daily accumulating milliseconds one second or 3600 at a time, bleed > them we must...and even people who loathe the very notion of leap > seconds admit this. NO, I DON'T ADMIT THAT. On the contrary, I deny it, flatly, roundly, and absolutely. > (The craven ITU proposal is obligated to pay lip > service to leap hours, though what they really are saying is "let's > close our eyes and wish it away".) Time to move on. The leap-hour proposal can be read as either (a) a serious proposal to inject an hour into UTC at some future date, or (b) a cynical proposal to abandon leap seconds and not replace them. I think (a) is just as foolish as leap seconds, if not more so. As for (b), it may be the best political approximation to what I really want, which is (c): abandon leap seconds altogether. "But then, soon enough, it won't be dark at !" Yes it will, just not in the skies over Greenwich. Practical difficulties can be overcome by making secular changes to the offsets between LCT and UTC, just as is done today when such problems arise. (In the next two years, the U.S., to name just one country, will make two secular changes to its LCT offsets.) The computerniks of the world already know how to handle such things, so future migrations will not be a problem. And people who want, for their legitimate purposes, to have access to UT1 will have to get it some other way. -- It was impossible to inveigle John Cowan <[EMAIL PROTECTED]> Georg Wilhelm Friedrich Hegel http://www.ccil.org/~cowan Into offering the slightest apology http://www.reutershealth.com For his Phenomenology. --W. H. Auden, from "People" (1953)
Re: The opportunity of leap seconds
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >Astronomers use UT1. Astronomers use UTC. Astronomers are among the >biggest users of TAI and GPS and likely any other timescale you care >to name. And they certainly have a lot of trouble seeing the rest of the world in for the brightness of their own majesty. The only timescale I am interested in here is UTC, and astronomers are not even close to registering as a marginal group in the user communities of UTC. What Astronomers use UTC for, in your own many times repeated words, is "a convenient approximation of UT1", and consequently it follows that if instead of an approximation astronomers used the Real Thing, leap seconds could harmlessly be removed from UTC. >By your logic, the U.S. Surgeon General should be a chiropractor. Once the US government tries to shoulder their national deficit that would undoubtedly be a good idea. >[various ramblings] >Canoli = common basis for diverse time usage worldwide >Eclair = baseline representation of Earth orientation > >Unless we *completely* change our notion of Canoli, Canoli is tightly >constrained to follow Eclair simply by the fact that today and >tomorrow and the million days that follow are all required to be dark >at night and light in the day. Wrong on all points. Light of day and darkness of night already is, and for all relevant future can be, assured by governmental adjustments of the two functions government control in the formula: Civil Time(time) = UTC(time) + TimeZoneOffset(country, subdivision, time) + SeasonalOffset(country, subdivision, time) >[various ramblings] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
On Sat 2006-01-07T13:06:13 -0500, John Cowan hath writ: > Well, yes. But that's a matter of verbal labels. The Gregorian calendar > extends to all future time: what is not known is the date on which it > will be replaced in civil use by a further refinement. We know we will > need one eventually, both because of the current annual discrepancy of > about 27 seconds between the Gregorian and tropical years, and because > of future changes in the length of the tropical year. The changes in the length of any kind of year are slight by comparison to the changes in length of day. Neglecting "short" period variations the length of the sidereal year has not changed much in a billion years. The best plot I've found for this is on this page http://inms-ienm.nrc-cnrc.gc.ca/en/faq_time_e.php It is not clear that this calculation reflects the intent of any particular agent in the schemes of calendrical design, or which. It is relevant to note that the original design of the Gregorian calendar did not intend to match the length of the tropical year, but rather to keep the March equinox happening on the 21st. As pointed out by Duncan Steel in his book on the calendar, the length of the tropical year (in phase with the precession) differs from the length of the "vernal equinox year". Their lengths differ because the perihelion drifts with respect to the equinox. The Gregorian calendar was designed to match the "vernal equinox year". All of these quantities require some agreement on the meaning of "mean" and "short" period variations. One aspect of Duncan Steel's book is that it relates the technical aspects with the social aspects, and the religious ones. Steel points out that for cultural purposes of calendrical design, the world always comes to an end within roughly 1000 years. The new fields being added to GPS signals make them able to count leap seconds for 3 years. That's quite an example of engineering margin. -- Steve Allen <[EMAIL PROTECTED]>WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: The real problem with leap seconds
Ed Davies scripsit: > (There's a small difference in practice in that the UTC to > TAI conversion requires a lookup table which is not known > very far into the future whereas the Gregorian calendar is > defined algorithmically for all time.) Well, yes. But that's a matter of verbal labels. The Gregorian calendar extends to all future time: what is not known is the date on which it will be replaced in civil use by a further refinement. We know we will need one eventually, both because of the current annual discrepancy of about 27 seconds between the Gregorian and tropical years, and because of future changes in the length of the tropical year. -- John Cowan [EMAIL PROTECTED] www.reutershealth.com www.ccil.org/~cowan If a traveler were informed that such a man [as Lord John Russell] was leader of the House of Commons, he may well begin to comprehend how the Egyptians worshiped an insect. --Benjamin Disraeli
The opportunity of leap seconds
On Jan 7, 2006, at 8:02 AM, Poul-Henning Kamp wrote: I have no problems with different timescales for different purposes. Great! Consensus reached! Rejoicing in all the lands! May one suggest a parade in celebration? The great Parade of the Leap Seconds! To be held on December 31 or June 30 as the spirit moves us (or January or July 1, for those east of Greenwich.) Now, what would that be in French? La Parade du Saut de Seconde? For instance I very much wish the Astronomers would start to use UT1, which is very much "their" timescale, and stop abusing UTC, which isn't, as a "convenient approximation". ...o - should have stopped while you were ahead. Astronomers use UT1. Astronomers use UTC. Astronomers are among the biggest users of TAI and GPS and likely any other timescale you care to name. Our community cares deeply about time. How precisely does this disqualify us from participating in the process? By your logic, the U.S. Surgeon General should be a chiropractor. Civil time is in the hands of individual governments, and they tend to expect their computers to use the same time as the rest of their country. The proper response to this comes down to us from the staid and proper British, inheritors of the immortal legacy of Shakespeare and Dickens: Bollocks! (http://en.wikipedia.org/wiki/Bollocks) We can incessantly debate trivialities, or we can seek a grand vision of the shared meaning of time in human concerns. I presume everybody here is competent to perform the conversions between different local clocks. Some have been instrumental in the construction of new systems of time for manifold scientific, technical and civil purposes. The following assertion thus falls flat: Nobody here is in any position to do anything about civil time or legal time, neither are we in a position to introduce a "computer time scale" in a pathetic attempt to paste over leap seconds. Geez! Cut the guy a break for coming late to the discussion. For his first posting, he has already elucidated a central issue of the debate. Would be nice if the ITU were debating the issues raised by Kuhn and Sokolov, rather than engaging in the political shenanigans you appear to applaud. ...but your upbeat speech has won my vote if you choose to run for student body president. For six years we've pretended that Coordinated Universal Time, and thus the concept of a leap second, is some extremely complicated issue of import only to technical wonks like us. Balderdash. It's fine if you want to challenge my definitions for particular terms. Fine, fine, fine. So instead of "Civil Time" and "Solar Time", slap new names on my definitions: Canoli = common basis for diverse time usage worldwide Eclair = baseline representation of Earth orientation Unless we *completely* change our notion of Canoli, Canoli is tightly constrained to follow Eclair simply by the fact that today and tomorrow and the million days that follow are all required to be dark at night and light in the day. Whether we choose to bleed off the daily accumulating milliseconds one second or 3600 at a time, bleed them we must...and even people who loathe the very notion of leap seconds admit this. (The craven ITU proposal is obligated to pay lip service to leap hours, though what they really are saying is "let's close our eyes and wish it away".) Time to move on. Or another analogy: Canoli is an arrow, Eclair its target. Canoli can be arbitrarily small, Eclair arbitrarily distant. Canoli is constrained to fly straight, thus an arbitrarily small choice of aiming options will result in hitting Eclair. Or consider the network time protocol. NTP can update the local clock on an arbitrary schedule. Two popular choices are daily on the one hand and "continuously" on the other. I suspect we dastardly astronomers are not alone in preferring the latter (small, frequent, fractional "leaps") rather than the former (large, rare, colossally arbitrary jumps). Rob Seaman National Optical Astronomy Observatory
Re: The real problem with leap seconds
Hi Ed, Poul-Henning Kamp wrote: What a weird concept... Why not go the full distance and define a timescale for each particular kind of time-piece: and give each of them their own unique way of coping with leapseconds ? Ignoring the ridiculous parody - no, it's not a weird concept. Different timescales are useful for different purposes. Get used to it. The question is, where in the range of possible timescales is it most useful to put civil time. Ed. I was contemplating an answer along the same lines. Yours is much superior. Rob
Re: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Ed Davies writes: >Ignoring the ridiculous parody - no, it's not a weird concept. >Different timescales are useful for different purposes. Get >used to it. I have no problems with different timescales for different purposes. For instance I very much wish the Astronomers would start to use UT1, which is very much "their" timescale, and stop abusing UTC, which isn't, as a "convenient approximation". But I have big problems with people who want to introduce more timescales without thinking through the legal and technical complications. >The question is, where in the range of possible timescales is >it most useful to put civil time. Civil time is in the hands of individual governments, and they tend to expect their computers to use the same time as the rest of their country. Nobody here is in any position to do anything about civil time or legal time, neither are we in a position to introduce a "computer time scale" in a pathetic attempt to paste over leap seconds. We can talk about _representation_ of a given timescale in computers, but there are far too many laws to rewrite if we want to dictate which timescale they should use. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
leap seconds are evil, no really
Incontrovertible proof from the web: Leap seconds increase traffic deaths in Australia http://www.thewaxconspiracy.com/wicked/gonzo/483.php Leap seconds cause flooding in a regional creek http://www.insidebayarea.com/sanmateocountytimes/localnews/ci_3380248 Leap seconds promote the creation of questionable music http://createdigitalmusic.com/index.php?option=com_content&task=view&id=1087 -- Steve Allen <[EMAIL PROTECTED]>WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: The real problem with leap seconds
Michael Sokolov wrote: Hello, I am a new entrant into the leap second debate and I have just written a paper in which I have outlined what I think is the real problem with UTC and leap seconds as they are currently implemented and a proposed solution. I have put the article on my web page: http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt The short summary is that I believe the root problem is not the adjustments made to the civil time scale to match Earth's rotation, but the fact that UTC is not expressible as a real number. UTC is expressible as a real number in just the same way that Gregorian dates (with months with different lengths and leap days) can be with the Julian calendar. There's no difference in principle between converting from a TAI time in seconds since some epoch to a UTC date/time in days, hours, minutes, seconds and fractions of a second and converting from an MJD day number to a Gregorian date in years, months, days and fractions of a day. (There's a small difference in practice in that the UTC to TAI conversion requires a lookup table which is not known very far into the future whereas the Gregorian calendar is defined algorithmically for all time.) You are sort of right, though, in that where computer systems typically get screwed up is in trying to assign a number to UTC seconds which is both a count since some epoch but also able to be taken modulo 86 400 to give a day number. This is, of course, impossible. What Markus Kuhn's UTS proposal was about was trying to reach a standard compromise which worked for such software - typically in cases where uniquely labeling the times of events is more important than exact interval determination. Ed.
Re: The real problem with leap seconds
Poul-Henning Kamp wrote: What a weird concept... Why not go the full distance and define a timescale for each particular kind of time-piece: and give each of them their own unique way of coping with leapseconds ? Ignoring the ridiculous parody - no, it's not a weird concept. Different timescales are useful for different purposes. Get used to it. The question is, where in the range of possible timescales is it most useful to put civil time. Ed.
Re: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Ed Davies writes: >Also, Markus wasn't proposing UTS as a civil timescale but just >for use within computer systems, etc. What a weird concept... Why not go the full distance and define a timescale for each particular kind of time-piece: Wrist Watch time Wall clock time Grandfather clock time Tower clock time Television time Embedded system time Appliance time Router time PC time Windows server time Commercial UNIX time Free UNIX time Main-frame time and give each of them their own unique way of coping with leapseconds ? Ohh wait... That's what it looks like today already isn't it ? :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
Steve Allen wrote: On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ: http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt If I read it right you have reinvented Markus Kuhn's UTS as seen in http://www.cl.cam.ac.uk/~mgk25/uts.txt http://www.cl.cam.ac.uk/~mgk25/time/leap/ http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf That's my reading too, except that Markus proposed batches of about 1000 UTS seconds either approximately 1.001 or 0.999 SI seconds long which seems like a better idea to me. Also, Markus wasn't proposing UTS as a civil timescale but just for use within computer systems, etc. Ed.
Re: HBG transmitted wrong info during leapsecond
In message <[EMAIL PROTECTED]>, Markus Kuhn writes: >Which was also noted at > > http://wwwhome.cs.utwente.nl/~ptdeboer/ham/sdr/leapsecond.html Right, but I think my data has a bit more resolution etc. I'm demodulating Rugby right now (will take half a day or so) and after that I'll go after France Inter's phase modulation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: HBG transmitted wrong info during leapsecond
Which was also noted at http://wwwhome.cs.utwente.nl/~ptdeboer/ham/sdr/leapsecond.html Various other LF 2005 leap second recordings are listed at http://www.cl.cam.ac.uk/~mgk25/time/lf-clocks/#leapsec2005 Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
HBG transmitted wrong info during leapsecond
Looks like the inserted the leapsecond after the minutemarker: http://phk.freebsd.dk/Leap/20051231_HBG/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes: >In message <[EMAIL PROTECTED]>, Steve Allen writes: >>On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: > >>At the beginning of 1984 and at the beginning of 2003 the branches of >>the IERS responsible for UT1 followed new IAU recommendations and >>changed the rules by which UT1 is calculated. The current version >>of UT1 has a notably different flavor and long-term purpose than >>the version of UT1 which was in place when UTC with leap seconds >>was originally defined by the CCIR. > doesn't v >But that matter, because ITU-R (successor of CCIR) defined Leap(time) >in terms of UT1 without specifying how UT1 was arrived at. oops... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Michael Sokolov writes: >http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt In this rather humorous document you have managed to say that POSIX screwed up badly. We already knew that :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message <[EMAIL PROTECTED]>, Steve Allen writes: >On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: >> UTC >> UTC(time) = TAI(time) + Leap(time) >> >> Owned by ITU. >> IERS evaluates Leap(time) according ITU definition > >Not quite. The endorsement for the usage of UTC comes from CGPM, >and that is predicated on the existence of leap seconds. This is irrelevant. The CGPM may endorse which timescale they think should go into legal time, but if they change their mind UTC will still exist until ITU does something about that. A secondary issue is that even if CGPM decided to say "Use FOO instead" nobody would take much notice until ITU and a lot of other people agreed and did their respective paperwork. >But in the original agreement, UTC and TAI were defined solely by the >BIH according to the rules of the CCIR. Both the BIH and the CCIR are >defunct. TAI was transferred from BIH to the BIPM. Determination of >the UTC offset was transferred from BIH to IERS. But IERS is not >a single entity, it is an ensemble of entities. Lets waste a lot of time splitting red tape, why don't we ? >At the beginning of 1984 and at the beginning of 2003 the branches of >the IERS responsible for UT1 followed new IAU recommendations and >changed the rules by which UT1 is calculated. The current version >of UT1 has a notably different flavor and long-term purpose than >the version of UT1 which was in place when UTC with leap seconds >was originally defined by the CCIR. But that matter, because ITU-R (successor of CCIR) defined Leap(time) in terms of UT1 without specifying how UT1 was arrived at. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)
In message <[EMAIL PROTECTED]>, William Thompson writes: >Poul-Henning Kamp wrote: > >> Universal Time = confusing term which comes handy when trying to >> manipulate discussions about leap second futures. > >I have to take issue with this one. My point was that when you just say "Universal Time", how will we know if you mean UTC, UT0, UT1 or UT2 ? >It's obvious from the current definition >and terminology used with Coordinated Universal Time that the original intent >was that UTC would be more-or-less synchronous with UT0, UT1, UT2. The current >debate is whether we should move away from that original intent. Correct: we are talking about what the Leap(time) function should do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: The real problem with leap seconds
On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ: > http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt If I read it right you have reinvented Markus Kuhn's UTS as seen in http://www.cl.cam.ac.uk/~mgk25/uts.txt http://www.cl.cam.ac.uk/~mgk25/time/leap/ http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf -- Steve Allen <[EMAIL PROTECTED]>WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m