Re: [LEAPSECS] New time scale name
> > Right, and it ticks based on UTC right now. Many systems have [...] Ok, I did read your email to the end. I had various rebuttles and alternatives, but after all these I'm not sure the end picture is better than the current system with leap seconds. However that other doc had "tracking UT1 more closely" as one of the options. They described it as a "non-starter". And I don't think it is a non-starter by any means. If you do manage think of a way it can work I'd like to hear more. I'm still keen to set up an NTP server that re-broadcasts UTC as UT1 so that any Unix Systems that want to sync their time to UT1 can use my server. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
In message: <1281716746.1929.51.ca...@localhost> Paul Sheer writes: : : > Best? This isn't an 'upgrade' at all, but rather returns to the : > 1960's practice of having "rubber" seconds. The UT1 second doesn't : > tick at a constant rate, so you have to constantly update the notion : > of the second. : > : : in the 1960's we didn't have the Internet - which is the most : widely used method of synchronizing clocks. Right, and it ticks based on UTC right now. Many systems have stability that are in excess of UT1's stability and moving to UT1 would break the statum 0 ones. : > : And drop further leap seconds of course. I have tried, but can't : > : find a system that would break because of this. : > : > All the stratum 0 NTP servers would break. : : : no, under my proposal the NTP servers would be "upgraded" to broadcast : TAI plus some smoothed out delta to match UT1. This is not a : "breakage". The migration would happen on a date where UTC and : UT1 exactly match which happens every couple of years. If the : NTP servers that are atomically based (or GPS based) had their : software upgraded first, then the time would be automatically : propogate to all other NTP servers. You misunderstand the problem. The problem is that GPS tracks GPS which track TAI. There's no UT1 information broadcast over GPS. Therefore, an NTP server that is slaved to GPS cannot possibly track UT1 because the UT1 offset information is not available to it. There's two problems here: UT1's frequency stability is inferior to GPS', but thankfully the stability is better than NTP normally gives. This stability can be a problem if you want your NTP server time to match the time that is going out other spigots (usually just PPS). So how do you track UT1 if your time source is UTC? The only way to do that is to get UT1 offsets often and model the time tracking based on that. : > The vast majority of them : > are based on GPS, which is based on UTC and cannot be based on UT1 : > since that would destroy the accuracy of GPS. If you mandate UT1 be : : GPS satelites have their own atomic clocks that keep in sync such : that GPS = TAI + 19 : : GPS devices use this clock for their position calculations - : this clock would not change under my proposal. This is good. Changing all the GPS units in the field would be difficult. : In actual fact under my proposal GPS could broadcast in their : offset field: : : floor(UT1 - TAI - 19) Which is exactly my point: You'd have to augment the GPS almanac with additional information. This sort of change would take years to : They wouldn't have to worry about leap seconds any more. Yes and no. UT1 - TAI time still has an evolving offset, just like UTC - TAI time. : Hand-held GPS devices would just show the wrong time by <1s. Why concede this point? If you have a UT1 - TAI offset, you can correct it. : > broadcast by NTP servers, then you'd need to find a way to get highly : > accurate (to 1ms) DUT1 data. This information isn't available in real : > time (although good estimates are). This information also isn't : : it is LEAP SECONDS that are currently not available! :-) That's also a problem in the current system, yes. However, the summary information for leap seconds is available. In the terrestrial broadcast formats, it is "leap pending", while in the GPS data stream it is current offset and future offset change. These are a complete table of leap information, but are sufficient to recover time from a GPS receiver (at least for the next 50ish or 100ish years when we'll overflow the leap offset fields). : Why would a function that produces a smoothed out UT1 be : any worse than a function that produces leap steps? : : The latter is what we currently have. : : My proposal is that we switch from a "smoothing function" that has : sharp steps in it to a smoothing function that is well.. smooth! UT1 isn't a completely smooth function. Currently, it is calculated for yesterday, with an estimate for the next several days. This function isn't smooth, but rather has more smaller discontinuities than UTC does today. : : > broadcast as part of GPS' almanac. There's a large number of NTP : > based on GPS networks that aren't Internet connected, so that would : > break them. : > : > : 2nd option is to keep leap seconds but upgrade the NTP and radio : > : protocols to give more warning - not 10 years warning, just *more* : > : warning. : > : > This is the sensible option that many people have been advocating. : > However, to do this right, you'd have to put more funding into : > modeling the earth, and also accept that you might, for periods of : > time, have > .9s divergence between UT1 and UTC. In order to do that, : > you have to deal with how to broadcast that information. There are : > sources of this data on the Internet, but the data format doesn't : > allow for > 1s representation of |DUT1|. : : : What I actually meant was this: : :
Re: [LEAPSECS] New time scale name
> Best? This isn't an 'upgrade' at all, but rather returns to the > 1960's practice of having "rubber" seconds. The UT1 second doesn't > tick at a constant rate, so you have to constantly update the notion > of the second. > in the 1960's we didn't have the Internet - which is the most widely used method of synchronizing clocks. > : And drop further leap seconds of course. I have tried, but can't > : find a system that would break because of this. > > All the stratum 0 NTP servers would break. no, under my proposal the NTP servers would be "upgraded" to broadcast TAI plus some smoothed out delta to match UT1. This is not a "breakage". The migration would happen on a date where UTC and UT1 exactly match which happens every couple of years. If the NTP servers that are atomically based (or GPS based) had their software upgraded first, then the time would be automatically propogate to all other NTP servers. > The vast majority of them > are based on GPS, which is based on UTC and cannot be based on UT1 > since that would destroy the accuracy of GPS. If you mandate UT1 be GPS satelites have their own atomic clocks that keep in sync such that GPS = TAI + 19 GPS devices use this clock for their position calculations - this clock would not change under my proposal. In actual fact under my proposal GPS could broadcast in their offset field: floor(UT1 - TAI - 19) They wouldn't have to worry about leap seconds any more. Hand-held GPS devices would just show the wrong time by <1s. > broadcast by NTP servers, then you'd need to find a way to get highly > accurate (to 1ms) DUT1 data. This information isn't available in real > time (although good estimates are). This information also isn't it is LEAP SECONDS that are currently not available! :-) Why would a function that produces a smoothed out UT1 be any worse than a function that produces leap steps? The latter is what we currently have. My proposal is that we switch from a "smoothing function" that has sharp steps in it to a smoothing function that is well.. smooth! > broadcast as part of GPS' almanac. There's a large number of NTP > based on GPS networks that aren't Internet connected, so that would > break them. > > : 2nd option is to keep leap seconds but upgrade the NTP and radio > : protocols to give more warning - not 10 years warning, just *more* > : warning. > > This is the sensible option that many people have been advocating. > However, to do this right, you'd have to put more funding into > modeling the earth, and also accept that you might, for periods of > time, have > .9s divergence between UT1 and UTC. In order to do that, > you have to deal with how to broadcast that information. There are > sources of this data on the Internet, but the data format doesn't > allow for > 1s representation of |DUT1|. What I actually meant was this: NTP packets have just one flag in them that says there is a leap second at the end of the current DAY. This is insane. It should have an array of integer fields to say WHEN there are leap seconds in the coming YEAR. A YEAR notice is totally do-able. No extra "modeling of the earth" is required. :-) If this is implemented this means that clients need only query once a year to get this info. Currently they have to query EVERY DAY! And this is the REAL problem. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
In message: <20100813090057.15429.qm...@protonet.co.za> p...@2038bug.com writes: : From all I've heard it seems best to make UTC and UT1 identical, : and to start broadcasting UT1 over the radio and NTP networks. Best? This isn't an 'upgrade' at all, but rather returns to the 1960's practice of having "rubber" seconds. The UT1 second doesn't tick at a constant rate, so you have to constantly update the notion of the second. : And drop further leap seconds of course. I have tried, but can't : find a system that would break because of this. All the stratum 0 NTP servers would break. The vast majority of them are based on GPS, which is based on UTC and cannot be based on UT1 since that would destroy the accuracy of GPS. If you mandate UT1 be broadcast by NTP servers, then you'd need to find a way to get highly accurate (to 1ms) DUT1 data. This information isn't available in real time (although good estimates are). This information also isn't broadcast as part of GPS' almanac. There's a large number of NTP based on GPS networks that aren't Internet connected, so that would break them. : 2nd option is to keep leap seconds but upgrade the NTP and radio : protocols to give more warning - not 10 years warning, just *more* : warning. This is the sensible option that many people have been advocating. However, to do this right, you'd have to put more funding into modeling the earth, and also accept that you might, for periods of time, have > .9s divergence between UT1 and UTC. In order to do that, you have to deal with how to broadcast that information. There are sources of this data on the Internet, but the data format doesn't allow for > 1s representation of |DUT1|. : 3rd (worst) option is to just stop announcing leap seconds. This also suffers from the same problems as #2. Warner : -paul : ___ : LEAPSECS mailing list : LEAPSECS@leapsecond.com : http://six.pairlist.net/mailman/listinfo/leapsecs : : ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
In message: <20100813112006.17784.qm...@protonet.co.za> p...@2038bug.com writes: : Jonathan E. Hardis writes: : : > On Aug 13, 2010, at 5:00 AM, p...@2038bug.com wrote: : >> All this talk of GMT/UTC/Legislature makes me ask how the world : >> currently syncs their time. : > http://www.bipm.org/en/scientific/tai/tai.html The best method is : > Two-Way Satellite Time and Frequency Transfer (TWSTFT), utilized by : > those laboratories with green dots. The others use some method of GPS : > common-view, such as Single Channel (SC) or Multi-Channel (MC). : : : This is not how 100's of millions of computers on the Internet sync : their time. : : It is merely how a handful of scientific labs sync their time. GPS time sync is a lot more common than that. Somewhere between tens and hundreds of thousands of GPS-driven NTP servers are sold every year. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
On Fri, 2010-08-13 at 08:06 -0400, ashtongj wrote: > For more information about one of the radio time and frequency stations, see > > http://www.nist.gov/physlab/div847/grp40/wwv.cfm > I am aware of these One of my previous companies was building an embedded device that used this signal to close fire-doors on time. And it too did not require accuracy <1s and didn't need to be in sync with anything. If these are the sort of applications then they could shift to UT1 with no problem. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
For more information about one of the radio time and frequency stations, see http://www.nist.gov/physlab/div847/grp40/wwv.cfm Gerry Ashton On 2010-08-13 7:44 AM, p...@2038bug.com wrote: This is very interesting. But I do notice the words "supposed to" and "could cause". Would you be able to find out more about how these systems use these ticks end-to-end? Are these ticks currently synced to UTC? If so, then how? Or do they have standalone clocks? Who uses these ticks? For what? Do the systems that use it count time and do they need that time to be in sync with other systems? -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
If, for sake of discussion, we view TAI as correct, then according to HP Application Note 1289, The Science of Timekeeping, D. W. Allen, N. Ashby, and C. C. Hodge, the irregularities in the rotation of the earth are at the level of 1.5 × 10^-9 (page 20). Frequency transfer using HF radio broadcasts can be performed at the level of 10^-6 to 10^-8, and with LF radio broadcasts, the level is 10^-10 to 10^-11 (pg. 73). Currently, the FCC requires base stations for some public safety radios to have a frequency stability of 1^10-7 (47 CFR section 90.213) which radio technicians who do not necessarily have a university degree will have to be able to verify compliance to this level. So we see everyday needs and capabilities are bumping up against the fundamental frequency stability of UT1 right now. One supposes the requirements will only become tighter in the future. For several decades now, the frequency of the radio broadcasts has agreed with the time ticks (or at least, that is supposed to happen). If the ticks were instead providing UT1 while the carrier frequency continued to be calibrated to the SI second, this could cause widespread effects that have not been examined. This is very interesting. But I do notice the words "supposed to" and "could cause". Would you be able to find out more about how these systems use these ticks end-to-end? Are these ticks currently synced to UTC? If so, then how? Or do they have standalone clocks? Who uses these ticks? For what? Do the systems that use it count time and do they need that time to be in sync with other systems? -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
Jonathan E. Hardis writes: On Aug 13, 2010, at 5:00 AM, p...@2038bug.com wrote: All this talk of GMT/UTC/Legislature makes me ask how the world currently syncs their time. http://www.bipm.org/en/scientific/tai/tai.html The best method is Two-Way Satellite Time and Frequency Transfer (TWSTFT), utilized by those laboratories with green dots. The others use some method of GPS common-view, such as Single Channel (SC) or Multi-Channel (MC). This is not how 100's of millions of computers on the Internet sync their time. It is merely how a handful of scientific labs sync their time. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
If, for sake of discussion, we view TAI as correct, then according to HP Application Note 1289, The Science of Timekeeping, D. W. Allen, N. Ashby, and C. C. Hodge, the irregularities in the rotation of the earth are at the level of 1.5 × 10^-9 (page 20). Frequency transfer using HF radio broadcasts can be performed at the level of 10^-6 to 10^-8, and with LF radio broadcasts, the level is 10^-10 to 10^-11 (pg. 73). Currently, the FCC requires base stations for some public safety radios to have a frequency stability of 1^10-7 (47 CFR section 90.213) which radio technicians who do not necessarily have a university degree will have to be able to verify compliance to this level. So we see everyday needs and capabilities are bumping up against the fundamental frequency stability of UT1 right now. One supposes the requirements will only become tighter in the future. For several decades now, the frequency of the radio broadcasts has agreed with the time ticks (or at least, that is supposed to happen). If the ticks were instead providing UT1 while the carrier frequency continued to be calibrated to the SI second, this could cause widespread effects that have not been examined. Gerry Ashton On 2010-08-13 5:00 AM, p...@2038bug.com wrote: UTC cannot exist without [...] All this talk of GMT/UTC/Legislature makes me ask how the world currently syncs their time. In the case of SMS networks - they use NTP or nothing. In the case of in-house business systems - they use NTP or nothing. In the case of Internet hosts - DNS/SMTP servers - they use NTP or nothing. Then there are many embedded devices that use the radio time signal. Then there are a few atomic time clocks for specialized cases not part of the NTP network. What else? The point is that there is *small* number of time syncronization "networks" used by *everybody*. When you talk about changing this or that standard, it is meaningless unless you ask also how these systems are going to deal with it. This is analogous to the IPv6 upgrade debate. There is no point defining new standards unless you also have a: 1. VIABLE UPGRADE PATH 2. REASON TO UPGRADE 3. COMPATIBILITY BETWEEN SYSTEMS THROUGH AND AFTER THE UPGRADE These other conversations would have made sense before the age of the Internet. From all I've heard it seems best to make UTC and UT1 identical, and to start broadcasting UT1 over the radio and NTP networks. And drop further leap seconds of course. I have tried, but can't find a system that would break because of this. 2nd option is to keep leap seconds but upgrade the NTP and radio protocols to give more warning - not 10 years warning, just *more* warning. 3rd (worst) option is to just stop announcing leap seconds. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
On Aug 13, 2010, at 5:00 AM, p...@2038bug.com wrote: All this talk of GMT/UTC/Legislature makes me ask how the world currently syncs their time. http://www.bipm.org/en/scientific/tai/tai.html The best method is Two-Way Satellite Time and Frequency Transfer (TWSTFT), utilized by those laboratories with green dots. The others use some method of GPS common-view, such as Single Channel (SC) or Multi-Channel (MC). - Jonathan ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
UTC cannot exist without [...] All this talk of GMT/UTC/Legislature makes me ask how the world currently syncs their time. In the case of SMS networks - they use NTP or nothing. In the case of in-house business systems - they use NTP or nothing. In the case of Internet hosts - DNS/SMTP servers - they use NTP or nothing. Then there are many embedded devices that use the radio time signal. Then there are a few atomic time clocks for specialized cases not part of the NTP network. What else? The point is that there is *small* number of time syncronization "networks" used by *everybody*. When you talk about changing this or that standard, it is meaningless unless you ask also how these systems are going to deal with it. This is analogous to the IPv6 upgrade debate. There is no point defining new standards unless you also have a: 1. VIABLE UPGRADE PATH 2. REASON TO UPGRADE 3. COMPATIBILITY BETWEEN SYSTEMS THROUGH AND AFTER THE UPGRADE These other conversations would have made sense before the age of the Internet. From all I've heard it seems best to make UTC and UT1 identical, and to start broadcasting UT1 over the radio and NTP networks. And drop further leap seconds of course. I have tried, but can't find a system that would break because of this. 2nd option is to keep leap seconds but upgrade the NTP and radio protocols to give more warning - not 10 years warning, just *more* warning. 3rd (worst) option is to just stop announcing leap seconds. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
On 12 Aug 2010, at 21:25, Michael Deckers wrote: > > I fear that the matter is less simple. The proposal keeps the > name UTC for the newly defined timescale. (And unfortunately, > there is precedent with essential changes in definitions of well > established time scales: GMT.) AIUI the UT* terms disambiguate the various meanings of GMT (ish). Perhaps the name UTC will be superseded in a similar way, becoming ambiguous and replaced by new terms. > So that, absurdly, those people > who continue to use UTC in the established sense could not keep > the well-established name for it -- they would have to find a > new name to avoid ambiguity (eg, UTL for UT with leap seconds). UTC cannot exist without a recognised authority who determines when leap seconds occur. If that authority stops adding leap seconds and breaks the |DUT1| < 0.9s guarantee I doubt anyone will take over the job. It would probably be easier to switch over to using the GPS time scale and ephemeris. GMT was also tied to a particular maintenance regime and stopped being a precise timescale when it was no longer being maintained. Tony. -- f.anthony.n.finchhttp://dotat.at/ ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
On 2010-08-11T17:14Z, Tony Finch wrote: On Wed, 11 Aug 2010, ashtongj wrote: > If dropping leap seconds is ultimately approved, we will need at least two > names for the new time scale. Alternatively, name the successor to UTC "TI" and if you want proleptic TI call it "proleptic TI". I fear that the matter is less simple. The proposal keeps the name UTC for the newly defined timescale. (And unfortunately, there is precedent with essential changes in definitions of well established time scales: GMT.) So that, absurdly, those people who continue to use UTC in the established sense could not keep the well-established name for it -- they would have to find a new name to avoid ambiguity (eg, UTL for UT with leap seconds). Everybody else does not rely on the precise definition; they can (and should) continue to use the name UTC without even knowing that it had changed definitions. Which is, I have to admit it, the charm of the proposal: those who need to know the exact definition of UTC old and new would have to change the name for the continuation of UTC in the old sense, along with quite a bit of their other software. But the rest of us (the overwhelming majority) need not care. Would the ITU-R care to give a name to the time scale that continues the old definition of UTC? I guess they wouldn't -- this is probably not seen as a technical question, even though systematic terminology is a technically important matter, in my opinion. So this might be the real terminological challenge: we need a new name for the time scale defined in the way that UTC currently is. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
On Wed, 11 Aug 2010, ashtongj wrote: > If dropping leap seconds is ultimately approved, we will need at least two > names for the new time scale. Alternatively, name the successor to UTC "TI" and if you want proleptic TI call it "proleptic TI". Tony. -- f.anthony.n.finchhttp://dotat.at/ IRISH SEA: NORTHWEST 4 OR 5, INCREASING 6 AT TIMES. SLIGHT OR MODERATE. SHOWERS. GOOD. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
