Re: A lurker surfaces
Ashley Yakeley wrote: I'd like to see an elastic civil second to which SI nanoseconds are added or removed. Perhaps this could be done annually: at the beginning of 2008, the length of the civil second for the year 2009 would be set, with the goal of approaching DUT=0 at the end of 2009. This was tried, between 1961 and 1972. It sucked. There is a big problem with having two kinds of second in common use, especially with such close values. They get mixed up. It is very convenient to have civil days made up of SI seconds, even if the number of one in the other has to vary in order to fit. A technical issue: broadcast time signals are phase-locked with the carrier, which is at some exact number of hertz. If the time pulses are every civil second, and that is now 1.00015 s (as it was in 1961), it can't be synchronised with the (say) 60 kHz carrier that must still have exactly 6 cycles per SI second. The historical trend is towards using uniform time units. It seems curious now that when the atomic clock was invented astronomers opposed calling it a time standard. They wanted to keep the Earth's rotation as the ultimate time, and accepted atomic clocks only as *frequency* standards. It is much like the ancient Egyptians (IIRC) making the transition from sundials to water clocks. They had always marked out hours on sundials subtending equal angles, so the actual temporal length of the hours varied over the course of the day. When the water clock gave them an independent time reference, they were horrified that its uniform hours didn't match sundial hours. Much technical ingenuity went into mechanical modifications to water clocks to make them accurately emulate what went before. Actually I was going to suggest that everyone observe local apparent time, and include location instead of time-zone, but I think that would make communication annoying. Yes. It would be a big step backward. Look up the history that led to the adoption of standard timezones: it was prompted by the invention of railways and telegraph. The trend in this area is towards increasing agreement of time over progressively larger geographical regions. Projecting into the future, one can foresee the eventual abandonment of timezones in favour of the universal use of Universal Time. -zefram
Re: A lurker surfaces
Zefram wrote: ... The historical trend is towards using uniform time units. It seems curious now that when the atomic clock was invented astronomers opposed calling it a time standard. Well, it seems curious to everybody except Rob Seaman :-) ... It is much like the ancient Egyptians (IIRC) making the transition from sundials to water clocks. They had always marked out hours on sundials subtending equal angles, so the actual temporal length of the hours varied over the course of the day. When the water clock gave them an independent time reference, they were horrified that its uniform hours didn't match sundial hours. Much technical ingenuity went into mechanical modifications to water clocks to make them accurately emulate what went before. ... Nice analogy. Ed.
Re: A lurker surfaces
Zefram scripsit: Projecting into the future, one can foresee the eventual abandonment of timezones in favour of the universal use of Universal Time. I think that's over the top. Bureaucratically it is just too annoying if the large majority of people have a work shift that overlaps legal midnight. -- On the Semantic Web, it's too hard to prove John Cowan[EMAIL PROTECTED] you're not a dog. --Bill de hOra http://www.ccil.org/~cowan
Re: Introduction of long term scheduling
Steve Allen wrote: On Mon 2007-01-01T21:19:04 +, Ed Davies hath writ: Why does the One sec at predicted intervals line suddenly diverge in the early 2500's when the other lines seem to just be expanding in a sensible way? ... I suspect that the divergence of the one line indicates that the LOD has become long enough that 1 s can no longer keep up with the divergence using whatever predicted interval he chose. I suspect that the chosen interval was every three months, for it is in about the year 2500 that the LOD will require 4 leap seconds per year. Yes, that make sense. I worked out what LOD increases he'd have to be assuming for one or 6 monthly leaps and neither seemed right. Should have realised that it was in between. Still, it's a strange assumption, given that TF.640 allows, I understand, leaps at the end of any month. Unofficially, the wording seems to be: A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. Anybody got access to a proper copy and can say whether that's right or not? If it is right then the Wikipedia article on leap seconds needs fixing. As for the other questions, McCarthy had been producing versions of this plot since around 1999, but the published record of them is largely in PowerPoint. Dr. Tufte has provided postmortems of both Challenger and Columbia as testaments to how little that medium conveys. Indeed, this slide hasn't got us much closer to understanding the original problem, namely: what is maximum error likely to be over a decade. Ed.
Re: A lurker surfaces
On Jan 1, 2007, at 22:56, Steve Allen wrote: Then let's improve the infrastructure for communicating the best estimation of earth orientation parameters. Then in a world of ubiquitous computing anyone who wants to estimate the current rubber-second-time is free to evaluate the splines or polynomials (or whatever is used) and come up with output devices to display that. This is fine, but leaves open the question of when 9:00am is here in Seattle. And why not transmit rubber-second-time as well, where technically feasible (such as over the internet)? What is a good source of earth orientation parameters, btw? -- Ashley Yakeley
Re: Introduction of long term scheduling
Warner Losh scripsit: There's an exception for IERS to step in two weeks in advance if the earth's rotation rate hickups. So if I understand this correctly, there could be as many as 14 consecutive days during which |DUT1| 0.9s before the emergency leap second can be implemented; consequently, the current guarantee is only statistical, not absolute. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat? No, I wouldn't, the beggar replied. Why is that? the Master asked. A Dinar doesn't go very far these days, Master.--Kehlog Albran Besides, the Temple of Toplat is across the street. The Profit
Re: A lurker surfaces
Then let's improve the infrastructure for communicating the best estimation of earth orientation parameters. Then in a world of ubiquitous computing anyone who wants to estimate the current rubber-second-time is free to evaluate the splines or polynomials (or whatever is used) and come up with output devices to display that. This is fine, but leaves open the question of when 9:00am is here in Seattle. And why not transmit rubber-second-time as well, where technically feasible (such as over the internet)? The technical problem is that many timing systems aren't connected to the internet. They are at secure installations and they only have GPS almanac data at their disposal. And, no, they aren't likely to ever be on the internet. Any changes would have to be announced a long time in advance, and GPS almanac would have to be updated to include more information. The second technical problem is that the length of a second is implicitly encoded in the carrier for many of the longwave time distribution stations. 10MHz is at SI seconds. For rubber seconds, the broadcast would drift into adjacent bands reserved for other things. Also, GPS would have to remain in SI seconds. The error in GPS time translates directly to an error in position. Approximately 1m/ns of error (give of take a factor of 3). Rubber seconds would require that the rubber timescale be off by as much as .5s. So GPS has to remain in GPS time (UTC w/o leap seconds, basically). That means that the rubberness of the seconds would need to be broadcast in the datastream. Many GPS receivers put out a PPS. This needs to be in SI seconds, or a number of other applications break. However, if one defined UTC in terms of these rubber seconds, then the top of UTC second would be out of phase with this PPS. That breaks a lot of assumptiosn that rightly assume that PPS is phase aligned to top of second. The interval math in UTC that's hard today would be significantly harder with rubber seconds. But it is just software, eh? In short, it is an interestingly naive idea that was tried in the 1960's and failed when there were only dozens of high precision time users rather than the hundreds of thousands there are today. The earth does not define the second any more. At most, it defines the day and the year. What is a good source of earth orientation parameters, btw? usno publishes several. Warner
Re: A lurker surfaces
On Jan 2, 2007, at 05:15, Zefram wrote: A technical issue: broadcast time signals are phase-locked with the carrier, which is at some exact number of hertz. If the time pulses are every civil second, and that is now 1.00015 s (as it was in 1961), it can't be synchronised with the (say) 60 kHz carrier that must still have exactly 6 cycles per SI second. The obvious solution is to transmit rubber time on a rubber frequency. -- Ashley Yakeley
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], John Cowan writes: Warner Losh scripsit: There's an exception for IERS to step in two weeks in advance if the earth's rotation rate hickups. So if I understand this correctly, there could be as many as 14 consecutive days during which |DUT1| 0.9s before the emergency leap second can be implemented; consequently, the current guarantee is only statistical, not absolute. But is it physically relevant ? Has anybody calculated how much energy is required to change the Earths rotation fast enough to make this rule relevant ? -- 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: Introduction of long term scheduling
Warner Losh scripsit: There's an exception for IERS to step in two weeks in advance if the earth's rotation rate hickups. So if I understand this correctly, there could be as many as 14 consecutive days during which |DUT1| 0.9s before the emergency leap second can be implemented; consequently, the current guarantee is only statistical, not absolute. I think I understand differently. BIH says on Jan 1 that the Februrary value of DUT1 is 0.2ms. If the earth hickups, IERS can step in by Jan 15th and say, no, the real correct value is 0.3ms. There's no provision for emergency leapseconds. They just have to be at the end of the month, and annoucned 8 weeks in advance. IERS has actually exceeded this mandate by announcing them ~24 weeks in advance in recent history. The IERS bulletin C is a little different than the ITU TF.460: Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. IERS is issuing Bulletin B as needed. The latest one can be found at ftp://hpiers.obspm.fr/iers/bul/buld/bulletind.dat . Right now DUT1 is +0.0s until further notice. From the last few B's, it looks like this is decreasing at about 300ms per year. This suggests that the next leap second will be end of 2008. Warner
Re: A lurker surfaces
On Jan 2, 2007, at 11:40, Warner Losh wrote: The second technical problem is that the length of a second is implicitly encoded in the carrier for many of the longwave time distribution stations. 10MHz is at SI seconds. For rubber seconds, the broadcast would drift into adjacent bands reserved for other things. At 1000ns, the carrier would drift by 10Hz. Surely the bandwidth is big enough for that? Also, GPS would have to remain in SI seconds. The error in GPS time translates directly to an error in position. Approximately 1m/ns of error (give of take a factor of 3). Rubber seconds would require that the rubber timescale be off by as much as .5s. So GPS has to remain in GPS time (UTC w/o leap seconds, basically). That means that the rubberness of the seconds would need to be broadcast in the datastream. GPS is TAI. I'm not proposing abandoning TAI for those applications that need it. -- Ashley Yakeley
Re: Introduction of long term scheduling
Warner Losh scripsit: There's no provision for emergency leapseconds. They just have to be at the end of the month, and annoucned 8 weeks in advance. IERS has actually exceeded this mandate by announcing them ~24 weeks in advance in recent history. So much the worse. That means that if the Earth hiccups on March 7, the value of |DUT1| will not return to normal until May 31. -- John Cowan[EMAIL PROTECTED]http://ccil.org/~cowan The whole of Gaul is quartered into three halves. -- Julius Caesar
Re: Introduction of long term scheduling
In message [EMAIL PROTECTED], Tony Fin ch writes: On Tue, 2 Jan 2007, Warner Losh wrote: Curiously, BIH is currently, at least in the document I have, expected to predict what the value of DUT1 is to .1 second at least a month in advance so that frequency standard broadcasts can prepare for changes of this value a month in advance. There's an exception for IERS to step in two weeks in advance if the earth's rotation rate hickups. I was amused by the dates in http://hpiers.obspm.fr/eoppc/bul/buld/bulletind.94 That's an interesting piece of data in our endless discussions about how important DUT1 really is... -- 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: Introduction of long term scheduling
In message: [EMAIL PROTECTED] John Cowan [EMAIL PROTECTED] writes: : Warner Losh scripsit: : : There's no provision for emergency leapseconds. They just have to be : at the end of the month, and annoucned 8 weeks in advance. IERS has : actually exceeded this mandate by announcing them ~24 weeks in advance : in recent history. : : So much the worse. That means that if the Earth hiccups on March 7, the : value of |DUT1| will not return to normal until May 31. Yes. But it would take a change in angular momementum would likely mean that |DUT1| being a little too large would be the least of our worries. The earthquake that hit Indonesia last year changed the time of day by microseconds. What would cause a sudden jump of hundreds of milliseconds hurts my brain to contemplate. Warner
Re: Introduction of long term scheduling
Warner Losh wrote: The IERS bulletin C is a little different than the ITU TF.460: Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Unfortunately, these IERS bulletins are dreadfully badly worded and seem to assume current practice rather than fully defining what they mean. E.g., Bulletin C 32, dated 19 July 2006 http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat says: NO positive leap second will be introduced at the end of December 2006. So we still don't know officially if there was a negative leap second then and we still don't officially know if there will be a leap second at the end of this month. http://hpiers.obspm.fr/iers/bul/bulc/BULLETINC.GUIDE says: UTC is defined by the CCIR Recommendation 460-4 (1986). It differs from TAI by an integral number of seconds, in such a way that UT1-UTC stays smaller than 0.9s in absolute value. The decision to introduce a leap second in UTC to meet this condition is the responsability of the IERS. According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June,and second preference to those at the end of March and September. Since the system was introduced in 1972 only dates in June and December have been used. Again, this is the truth but not the whole truth as it doesn't mention the third preference opportunities at the ends of other months - but it'll be a while until those are needed. (Also, they can't spell responsibility :-) Ed.
Re: Introduction of long term scheduling
Warner Losh wrote: Right now DUT1 is +0.0s until further notice. From the last few B's, it looks like this is decreasing at about 300ms per year. This suggests that the next leap second will be end of 2008. The way DUT1 is behaving at the moment, it looks like an ideal time for IERS to experiment with scheduling further ahead. It should be easy to commit today to having no leap second up to and including 2007-12, as a first step. Well, we can hope. -zefram
Re: A lurker surfaces
M. Warner Losh wrote: GPS is also used for UTC today. Many ntpd's are stratum 1 tied to a GPS receiver. I imagine two parallel time infrastructures, one synchronised to TAI, the other to rubber mean universal time. Stratum 0 devices for the latter would probably have to use radio. So, sure, there's an infrastructure cost for a sensible time of day... ntpd is UTC, by definition. I wonder how easily NTP could be generalised to transmit different timescales without too much confusion? Using different UDP port numbers might be one option. -- Ashley Yakeley
Re: A lurker surfaces
In message [EMAIL PROTECTED], Ashley Yakeley writes: M. Warner Losh wrote: GPS is also used for UTC today. Many ntpd's are stratum 1 tied to a GPS receiver. I imagine two parallel time infrastructures, one synchronised to TAI, the other to rubber mean universal time. Stratum 0 devices for the latter would probably have to use radio. This proposal is so patently badly researched that you should not talk more about it until you have _really_ thought about the implications, technical, scientifically and legally. -- 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: Introduction of long term scheduling
Ed Davies wrote: Still, it's a strange assumption, given that TF.640 allows, I understand, leaps at the end of any month. Unofficially, the wording seems to be: A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. Anybody got access to a proper copy and can say whether that's right or not? If it is right then the Wikipedia article on leap seconds needs fixing. The text you quoted is taken exactly fromITU-R Recommendation TF.640-4, Annex I (Time Scales), paragraph D (DUT1), sub-paragraph 2 (Leap-seconds): 2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September. 2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-seoond, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex III). 2.3 The IERS should decide upon and announce the introduction of a leap-second, such announcemtn to be made at least eight weeks in advance. -- James Maynard, K7KK Salem, Oregon, USA
Re: A lurker surfaces
Magnus Danielson wrote: The detailed introduction of the frequency corrections in various sources was different, and getting a coherent view of where UTC actually where was difficult. Since then we have grown to depend on UTC transmission to a higher degree than we did back then. Infact, for many purposes our UTC transmissions is also there to get us SI second traceability for a whole range of applications. If we brake the SI second in UTC a whole lot of technology will break. Rubber seconds would be a plain nightmare to introduce and maintain compared to the strange and slightly uncomforting dreams we have with the current leap second scheduling. If the list will forgive me for airily focussing on the ideal rather than the immediately practical... we should keep TAI and UTC as they are, but create a new timescale for civil time with a new name and its own separate infrastructure. Then we can persuade govenments to adopt it. UTC can then fade into irrelevance. No, GPS is not TAI. GPS run its own timescale and it is offset from TAI by 19 seconds, as given in BIPMs Circular T 227: I meant up to a known conversion. If you have some GPS time, you know it for TAI, and vice versa. That's not the case for UTC, since you don't know what the leap second offset will be if it's too far in the future. Of course you can also extract UTC from a GPS signal. -- Ashley Yakeley
Re: A lurker surfaces
From: Ashley Yakeley [EMAIL PROTECTED] Subject: Re: [LEAPSECS] A lurker surfaces Date: Tue, 02 Jan 2007 15:21:14 -0800 Message-ID: [EMAIL PROTECTED] Ashley, Magnus Danielson wrote: The detailed introduction of the frequency corrections in various sources was different, and getting a coherent view of where UTC actually where was difficult. Since then we have grown to depend on UTC transmission to a higher degree than we did back then. Infact, for many purposes our UTC transmissions is also there to get us SI second traceability for a whole range of applications. If we brake the SI second in UTC a whole lot of technology will break. Rubber seconds would be a plain nightmare to introduce and maintain compared to the strange and slightly uncomforting dreams we have with the current leap second scheduling. If the list will forgive me for airily focussing on the ideal rather than the immediately practical... we should keep TAI and UTC as they are, but create a new timescale for civil time with a new name and its own separate infrastructure. Then we can persuade govenments to adopt it. UTC can then fade into irrelevance. I do not think it is feasable to build a separate infrastructure. The pure economics of it is the prohibiting factor. If we could do it, then the rubber second would solve a certain particlar headache. But I am very very very pessimistic about it. The budget isn't there and the govrements already pay good money for the systems in place and is looking to get as much out of it as possible. Also, on the user equipment side it would require us to toss out a whole bunch of already paid for and perfectly running gear. This would cost much of the industry (medicin, telecom etc.) alot of money. You can be sure that they would be advocating against it. To put it bluntly, we are too deep in the shit to get out of it now. This is why a new timescale with all its new requirements wouldn't go very far. If you do want a new timescale, I think rubber seconds isn't going to be the solution. It needs to be SI second based one way or another. This means that you need to come up with something such as UTC. This is why I beleive that we should be looking on how to ease the pain of current UTC leap second schedules rather than inventing the wheel and getting it quite similar but not quite like the UTC. Just consider the confusion we have between GMT and UTC. Now with a third timescale it would become a mess to sort things out. These days when ordinary people (and most beurochrats) say GMT we can silently assume they meant to say UTC but if we are going to follow them to the letter we have trouble. So, yes... it would solve certain things, but I don't think it will happend. No, GPS is not TAI. GPS run its own timescale and it is offset from TAI by 19 seconds, as given in BIPMs Circular T 227: I meant up to a known conversion. If you have some GPS time, you know it for TAI, and vice versa. Indeed. But it was not what you wrote. That's not the case for UTC, since you don't know what the leap second offset will be if it's too far in the future. Of course you can also extract UTC from a GPS signal. You assume that you always convert UTC into TAI when you are given a UTC time. You don't need to. You can maintain your time in UTC and when the local UTC time (as corrected by received UTC leap seconds) reaches that time, you will get your even at the correct UTC time. You can resolve these issues, but you have to be aware that time differences needs to be done in TAI and future UTC timestamps needs to be done in UTC. You know this naturally, but we do lack the vehicle in some systems. Is this the fault of how UTC was built? No. Will a third time scale solve this? No. Will we eventually have to reform the UTC scale as we run out of leap second oppertunities? Yes, but not in our lifetime to the best of my knowledge. Cheers, Magnus
Re: A lurker surfaces
Magnus Danielson wrote: The budget isn't there and the govrements already pay good money for the systems in place and is looking to get as much out of it as possible. Yes, you're probably right, they're likely to prefer to patch up something ultimately broken cheaply than fix it properly. I think the best that can be hoped for in the short term is a user-created infrastructure among those who care enough to bother. And just agreeing what the lengths of the seconds should be, or even the schedule for specifying them, is likely to be hard enough. Indeed. But it was not what you wrote. Eh, GPS time is TAI. You just have to know about the odd encoding... -- Ashley Yakeley
Re: Wikipedia article
Ed Davies wrote: However, it's a horrible article and really needs reorganization as some of the paragraphs have suffered serious mission creep. I edited quite a lot of time-related articles last year, and couldn't figure out what to do with it. I started off with the articles on astronomical time scales, and worked in conceptual sequence over towards [[Coordinated Universal Time]]. [[International Atomic Time]] is mostly my work, but UTC is on the other side of the obscure/mainstream divide, and from there on I found myself hindered by other well-meaning editors. It seemed silly to me to have [[leap second]] distinct from [[UTC]]: leap seconds are the defining feature of UTC, after all. So my first effort was to merge them. This was too controversial, and my formal proposal to do it was roundly defeated. In retrospect, I think the mainstream view of UTC is as the base timezone, though that is really the job of the generic UT. Leap seconds seem to be viewed as an unimportant detail. I put as much as I could into [[UTC]]. It duplicates some of what is in [[leap second]]. I don't have a clear concept of what belongs in [[leap second]] that doesn't belong in [[UTC]], so in the end I left it as a collection of miscellaneous bits, which was pretty much how I had found it. Paragraphs and sections suffering mission creep has also occurred a bit in [[UTC]]. I failed to disentangle it all. I don't even like the first sentence. Intercalary seems wrong to me as a leap second is part of the day it is applied to, not between days. Intercalary is precisely the correct term. An intercalary day, as we have in the Gregorian calendar, is inserted between other days; an intercalary month, as in the Jewish lunisolar calendar, is inserted between other months; both are part of the year to which they are applied. An intercalary second is inserted between other seconds, and is part of the day to which it is applied. -zefram
Re: A lurker surfaces
From: Ashley Yakeley [EMAIL PROTECTED] Subject: Re: [LEAPSECS] A lurker surfaces Date: Tue, 02 Jan 2007 16:40:23 -0800 Message-ID: [EMAIL PROTECTED] Ashley, Magnus Danielson wrote: The budget isn't there and the govrements already pay good money for the systems in place and is looking to get as much out of it as possible. Yes, you're probably right, they're likely to prefer to patch up something ultimately broken cheaply than fix it properly. I think the best that can be hoped for in the short term is a user-created infrastructure among those who care enough to bother. And just agreeing what the lengths of the seconds should be, or even the schedule for specifying them, is likely to be hard enough. There is never such a thing as a perfect system in this game. We need to run of one or another of a whole set of approximation schemes. Whatever scheme we have or come up with, we have a number of different needs which in themselfs are conflicting. Whatever system we are running, it needs to be widely realizeable with sufficient precission as the many different usages require, and there are many customers around. It also needs to be well understood and supported by system designs throughout many types of equipment. Even if we can come up with a better scheme for some purposes, it needs to be manageable into the whole infrastructure in a fairly painless fashion. You can never get it quite right, but fairly painless is what you can hope fore. If we rebuilt all time distribution systems and all systems using time, we could do anything. Including rubber seconds which can be designed handle all expected rates of earth spinning in the next 1 years or so. Unfortunatly that is not a luxury we have. Technological and economical limitations is there and real. Not that we don't have technological and economical issues as it is, we do, but that even strengthen the point. So, I don't think we will get the perfect time solution ever. But behing humans as we are, we keep striving towards that unobtainable goal. I would do a whole lot of things differently if time and economics where not a limiting factor. In the meantime, I too will have to suffer approximations. Indeed. But it was not what you wrote. Eh, GPS time is TAI. You just have to know about the odd encoding... In order to know about the odd encoding you need to call it something else than TAI since is not EXACTLY as TAI. It is not even TAI plus some fixed number. You can make a darn good (given the money you need) TAI approximation off the GPS time. Another darn good approximation could I have if I plugged into say PTB-CS2. They are not the same and never will be. You can hower use the GPS time to getyourself a TAI approximation, but it never will be TAI. So GPS time is not TAI. Never will be. Given some compensation it is near thought. Cheers, Magnus
Re: A lurker surfaces
On 2 Jan 2007 at 12:40, Warner Losh wrote: The interval math in UTC that's hard today would be significantly harder with rubber seconds. But it is just software, eh? In short, it is an interestingly naive idea that was tried in the 1960's and failed when there were only dozens of high precision time users rather than the hundreds of thousands there are today. Actually, rubber seconds were what were in use for centuries, as the time calibrated to astronomical observations, with the second defined in terms of the length of a solar day, was what was in use (or, actually, a very rough approximation of it given the lack of accuracy of timepieces in the pre-atomic era). What was tried unsuccessfully in the 1960s was to actually define such timekeeping in a rigorous scientific way allowing conversion to and from atomic time. -- == 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: Introduction of long term scheduling
On 2 Jan 2007 at 19:40, Poul-Henning Kamp wrote: Has anybody calculated how much energy is required to change the Earths rotation fast enough to make this rule relevant ? Superman could do it. Or perhaps he could nudge the Earth's rotation just enough to make the length of a mean solar day exactly equal 86,400 SI seconds. -- == 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: A lurker surfaces
On 2 Jan 2007 at 11:47, Ashley Yakeley wrote: The obvious solution is to transmit rubber time on a rubber frequency. Are rubber duckies involved? -- == 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: A lurker surfaces
On 2 Jan 2007 at 11:56, Ashley Yakeley wrote: GPS is TAI. I'm not proposing abandoning TAI for those applications that need it. It's a few seconds off from TAI, isn't it? It was synchronized to UTC in 1980 (I think), but without subsequent leap seconds, so it's now different from both TAI and UTC. They probably should just have used TAI if they wanted a time scale without leap seconds, rather than ending up creating a different one. -- == 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: Introduction of long term scheduling
Daniel R. Tobias replies to Poul-Henning Kamp: Has anybody calculated how much energy is required to change the Earths rotation fast enough to make this rule relevant ? Superman could do it. Or perhaps he could nudge the Earth's rotation just enough to make the length of a mean solar day exactly equal 86,400 SI seconds. Only briefly. Consider the LOD plots from http://www.ucolick.org/ ~sla/leapsecs/dutc.html. The Earth wobbles like a top, varying its speed even if tidal slowing is ignored. Actually, rather than being merely a troublemaker, the Moon serves to stabilize the Earth's orientation. The Rare Earth Hypothesis makes a strong case that a large Moon and other unlikely processes such as continental drift are required for multicellular life to evolve, in addition to the more familiar issues of a high system metal content and a stable planetary orbit at a distance permitting liquid water. Without the Moon, the Earth could nod through large angles, lying on its side or perhaps even rotating retrograde every few million years. Try making sense of timekeeping under such circumstances. Rob Seaman NOAO
Re: A lurker surfaces
Magnus Danielson wrote: If you do want a new timescale, I think rubber seconds isn't going to be the solution. One might point out that many time scales do rely on rubbery seconds, e.g., sidereal time and apparent solar time. If might be enlightening to step back from the tendentious and tedious tug-of-war between UTC and TAI and reflect that even UT1 - a mean solar time scale - intrinsically has rubber seconds. Sexagesimal notation is clearly revealed as a way to express an angle - of Earth orientation in this case. The whole point of UTC is to permit Earth orientation to be approximated while using SI seconds. Rob Seaman NOAO
Re: Introduction of long term scheduling
Poul-Henning Kamp wrote: That's an interesting piece of data in our endless discussions about how important DUT1 really is... The point is that by allowing it to grow without reasonable bound, DUT1 would gain an importance it never had before.
Re: Wikipedia article
- Original Message - From: Ed Davies [EMAIL PROTECTED] To: LEAPSECS@ROM.USNO.NAVY.MIL Sent: Tuesday, January 02, 2007 3:55 PM Subject: [LEAPSECS] Wikipedia article Thanks to those who confirmed the ITU text on when leap seconds can be applied. I've made two small edits to the Wikipedia article to correct parts which were wrong or potentially misleading (plus a slightly tongue-in-cheek remark in the discussion page) However, it's a horrible article and really needs reorganization as some of the paragraphs have suffered serious mission creep. I don't even like the first sentence. Intercalary seems wrong to me as a leap second is part of the day it is applied to, not between days. I thought about changing it but decided I might be being a bit blinkered in my definition of intercalary. Thoughts? Ed. The French-language term for leap second is second intercalaire, so calling a leap second intercalary has a linguistic precedent if nothing else. Besides, the English term leap second is a misnomer--a leap year is a year with an extra day in it (and the inserted day is *not* called a leap day) so by analogy the insertion of a second should probably have been termed a leap minute. But that's all cesium over the dam, now. Brian
Re: A lurker surfaces
In message: [EMAIL PROTECTED] Daniel R. Tobias [EMAIL PROTECTED] writes: : On 2 Jan 2007 at 11:56, Ashley Yakeley wrote: : : GPS is TAI. I'm not proposing abandoning TAI for those applications : that need it. : : It's a few seconds off from TAI, isn't it? It was synchronized to : UTC in 1980 (I think), but without subsequent leap seconds, so it's : now different from both TAI and UTC. They probably should just have : used TAI if they wanted a time scale without leap seconds, rather : than ending up creating a different one. Yes. There's a fixed offset between seconds in TAI and seconds in GPS. The GPS timescale is tied to seconds in UTC(NRO). TAI is a paper clock, computed after the fact, so GPS can't ever be TAI time. However, the differences there are down in the nanosecond or so range. There's a big philosophical opposition to using the paper clock that is TAI in a real-time operational timescale that GPS uses. The European version of GPS originally specified TAI time, but this was changed in later revisions to be the same as GPS time. There's an extreme reluctance in the time community to call something without leap seconds TAI or TAI + fixed offset. TAI means something very specific. That's the other problem with just using TAI, btw, but explaining that point is very hard... The principle time scientist made me change the description of the output of measurment time for a product I did. I described it as TAI time seconds since 1970. Instead, he descriped it as Number of PPS ticks in the UTC time scale since 1972 + 63072000 + 10. Mathematically, they work out to be the same thing, but he was extremely resistant to calling it TAI time or using the TAI moniker for it at all. When I asked him about this, he said that TAI time isn't realized in real time, but UTC is. UTC is what one can measure against. Producing a number that corresponded to TAI time was OK, and likely the least confusing thing to do (we give a second number and UTC time in '-MM-DD HH:MM:SS Z' as well as the channel and the measurement for that time in out output), but actually calling it TAI would 'confuse' the really smart time geeks out in the world. I asked him for a reference where I could read up on this, and he shrugged and said he just knew it and didn't know of any good write up. Warner
Re: A lurker surfaces
From: Rob Seaman [EMAIL PROTECTED] Subject: Re: [LEAPSECS] A lurker surfaces Date: Tue, 2 Jan 2007 20:45:14 -0700 Message-ID: [EMAIL PROTECTED] Rob, Magnus Danielson wrote: If you do want a new timescale, I think rubber seconds isn't going to be the solution. One might point out that many time scales do rely on rubbery seconds, e.g., sidereal time and apparent solar time. If might be enlightening to step back from the tendentious and tedious tug-of-war between UTC and TAI and reflect that even UT1 - a mean solar time scale - intrinsically has rubber seconds. Sexagesimal notation is clearly revealed as a way to express an angle - of Earth orientation in this case. The whole point of UTC is to permit Earth orientation to be approximated while using SI seconds. Indeed. The civil usage require something like UT1 even if not precise UT1. UTC is one such solution. UT1 is as rubbery as it gets. Some transmissions include enought information for creating a local estimate of UT1, but not with sufficient level of resolution for all the uses we have. With the one-way (or indeed two-way) time transfer mechanisms now at our disposal we can remove much of the time offset between transmitter and receiver. You could therefore build UT1 realizations based on improved clock model and diverse parameters for UT1 realization. Technically it would be quite possible. You just need to add these parameters in order for a TAI/UTC transmission or for that matter UT1 transmission (with transmitter corrections). Even if rubbery, you should be able to build an smoothed UT1 realisation of quite high accuracy if you need to. However, this would result in several problems not only in the updating of the transmission system and the related receivers, for many other purposes we still require TAI traceability/stability as well as civil time alongside. With all its thorns UTC is IMHO a better solution than having to deal with two different types of seconds which moves around all the time. I view your comment as being astronomy-oriented (nothing wrong with that). However, for the type of systems which I normally wrap my head around the exact angle of Earth orientation is as such not very interesting, but on average it needs to be somewhere in the neighborhood of UT1 in the long run. There are usage for TAI, UTC and UT1. Do we need to invent one more? Do we need to make wider useage of UT1? Are the problems of UTC really that big? IMHO and to the best of my limited insight I still find those questions answered with a no. Cheers, Magnus
Re: A lurker surfaces
From: Steve Allen [EMAIL PROTECTED] Subject: Re: [LEAPSECS] A lurker surfaces Date: Tue, 2 Jan 2007 21:35:24 -0800 Message-ID: [EMAIL PROTECTED] On Tue 2007-01-02T22:16:19 -0700, M. Warner Losh hath writ: changed in later revisions to be the same as GPS time. There's an extreme reluctance in the time community to call something without leap seconds TAI or TAI + fixed offset. TAI means something very specific. That's the other problem with just using TAI, btw, but explaining that point is very hard... It would almost seem to consistent with established notation to define TAI(GPS) = GPS + 19 + W1K * n Actually, in BIPM Circular T they use another notation to avoid confusing TAI with that of a particular local TAI realization, TA(k). So the above formula would be TA(GPS) = GPS + 19 + C0 where C0 is being reported in Clause 5 of Circular T. Actually, they write it as: [UTC-GPS time] = -14 s + C0, [TAI-GPS time] = 19 s + C0, global uncertainty is of order 10 ns. (direct quote from Circular T No 227). For UTC they gladly refer to UTC and UTC(OP) or whatever laboratory they choose to discuss. Producing a number that corresponded to TAI time was OK, and likely the least confusing thing to do (we give a second number and UTC time in '-MM-DD HH:MM:SS Z' as well as the channel and the measurement for that time in out output), but actually calling it TAI would 'confuse' the really smart time geeks out in the world. I asked him for a reference where I could read up on this, and he shrugged and said he just knew it and didn't know of any good write up. This is my tail wags the dog point. The national metrology agencies are tasked by their national laws and funding agencies to produce the legal time scale for each country. Depending on the state of legislation that is either GMT or UTC. In the US the time agencies have chosen to interpret GMT as UTC by taking advantage of the imprecision of the federal law. The national metrology agencies are not *directly* tasked to keep TAI, but by being parties to the Metre Convention their own version of UTC plus leap seconds contributes to TAI. So each national contributing source to TAI is really based on that country's version of UTC. Despite the appearances of the equations the versions of UTC are the primary entities and TAI is secondary. Notice that some laboratories actually maintain their own TAI in addition to maintaining their own UTC. You can even see that they produce different data for UTC and TAI. And, yes, explaining all this is very hard. It's not obvious to the geek that the political and funding realities are more real than the underlying physics, but that's the way the world works. Indeed. I investigated the different translations of the European Commission summer time directive and it turns out that most translations referred to GMT where as only a few actually said UTC. It gives the filmtitle Lost in translation yeat another meaning. Sigh. Interestingly was the Danish translation indicating the transition times in UTC where as Denmark yeat has to legally accept UTC (where as it in reality thanks to a certain friend of ours here for all practicall reasons actually is UTC). Sigh. Cheers, Magnus
