Re: NOT A cruel fraud!
In message: [EMAIL PROTECTED] Ed Davies [EMAIL PROTECTED] writes: : Earlier, I wrote: : We all know that it (and any other world-wide timescale) is : postal at the level of the time it takes light to cross a : moderately small room but for microsecond precision and looser : this is not an issue. : : I ought to qualify that. There are, of course, time scales which : are synchronized across the world with much better than microsecond : precision (e.g., GPS time) but it's my understanding that they are : not anything like as uniform as TAI. Is this right? Can anybody : quote accuracy information for GPS time? At what level of precision : do time transfers using GPS time need out-of-band (postal) : correction for uniformity? GPS is synchronized to UTC(USNO) which agrees with UTC(NIST) to within a few nanoseconds. GPS receivers can recover UTC(USNO) to within about a few nanoseconds (as measured by a direct two way time exchange with NIST), although not all of them are that quality. The rms of a good timing receiver is on the order of nanoseconds. NIST and USNO coordinate with each other to make sure there's close agreement in the two minor variations of UTC. They also participate in the computation of TAI. TAI is computed after the fact based on the observed time of different frequency standards. Phase offsets between different time sources are measured, the data is decimated and placed into a particular format and sent to BIPM. These measurements are sent in batches and used to measure interesting effects. Here are some reports on how the various labs measure time relative to a known source: http://www.bipm.fr/cc/CCTF/Allowed/16/cctf04-18.pdf http://www.bipm.org/en/publications/scientif/tai.html Warner
Re: NOT A cruel fraud!
On Sun, 22 Jan 2006, M. Warner Losh wrote: The short answer is that you cannot get a time feed of TAI, so the So isn't this one of the things we want to fix in the brave new world of joined-up timekeeping? Distribute (very close to) TAI, keep the kernel PLLs sweet, move leap second handling to user-space and thus make debugging very easy, then everone can get their timescale of choice as a f(TAI)? Peter.
Re: the tail wags the dog
Steve Allen [EMAIL PROTECTED] wrote: The CGPM recommendation on the timescale everyone should use says UTC. UTC(insert your national time service here) is available in real time. TAI is the mathematical (really the political or diplomatic) entity upon which UTC is ostensibly based, but the practical and legal reality is the other way around. Has it occurred to any of you that *THIS* is the very root of the problem, that *THIS* is what we need to change? Also, isn't TAI readily available in real time from GPS? (How difficult can it be for the routine parsing the data stream from the GPS receiver to add 19?) OK, OK, it'll be TAI(GPS) rather than true TAI, but then your UTC is really UTC(NIST) or UTC(USNO) or UTC(PTB) or whatever rather than true UTC. MS
Re: NOT A cruel fraud!
Mr. Losh and I have apologized to each other, off list. I think we should now retire the cruel fraud subject line. -- James Maynard Salem, Oregon, USA
Re: Risks of change to UTC
John Cowan [EMAIL PROTECTED] wrote: Once we have accomplished the former [changing the basis of civil time], I don't give a hoot about the latter [hobbling UTC]. Keep UTC if you want. Then what are you doing here? Why don't you go to your elected representatives in whatever country you call yours and lobby them to pass a law changing the basis of civil time in your country from UTC to TAI-33s? I'm equally baffled by those people who keep trying to make ITU hobble UTC. Those people are from the US government, aren't they? Then if they are the US government, the all-powerful government that doesn't give a flying rat's ass about anybody but themselves, why do they bother with ITU, why don't they just pass a law changing the US legal time to TAI-05:00:33 on the East Coast, TAI-06:00:33 Central, etc. Surely the all-powerful government could do this any moment without asking anyone, certainly not the common citizens? MS
Re: the tail wags the dog
Michael Sokolov wrote: Steve Allen [EMAIL PROTECTED] wrote: TAI is the mathematical (really the political or diplomatic) entity upon which UTC is ostensibly based, but the practical and legal reality is the other way around. Has it occurred to any of you that *THIS* is the very root of the problem, that *THIS* is what we need to change? Frankly, I didn't understand Steve's remark at all. Practical reality is that most national standards laboratories use precise frequency standards to maintain a count of SI seconds as a rendition of TAI. When it comes to establishing and distributing UTC or legal time, they consult the publications of the IERS and/or local law, and do some simple math. Legal reality (I speak for The Netherlands) is also not the other way around but appears to ignores TAI and the leap second issue completely. Legal time is equated to CET (or CEST) which is considered sufficiently well-known to leave it at that. In practice, the VSL laboratory of the NMI in Delft, which is supposed to provide legal time, works as described above. I can imagine other countries are not much different. So from a legal standpoint, there is no problem. Countries will happily folow any standard the scientific community comes up with, finds general use, and is halfway usable. Like they did with UTC without caring a *** where it actually comes from. Nero Imhard Oegstgeest, The Netherlands
Re: Approach to leap second discussion
Rob Seaman wrote: I hope we can all continue this discussion in a more positive manner. I'm of the opinion that messages on this list (no matter how tricky :-) are always positive. Timekeeping is a fundamental issue. It would be remarkable if there weren't diverse opinions. Any negative aspects of this discussion are related to those who don't choose to participate. Which is to say, those who claim to have decision making authority over UTC at the ITU, for instance. The folks on this list appear to cluster into two groups (speak up if your opinion diverges from both): 1) Civil time should remain layered on UTC. UTC should remain largely unchanged. Leap seconds should continue. and 2) Civil time should be layered on some flavor of interval time. That timescale might be a variation of TAI called TI. TI will not have leap seconds. OK so far. Actually, I've yet to see any argument which would make me deeply unhappy with either of these outcomes. The proposal submitted to the ITU is neither of these. It is: 3) Civil time should remain layered on UTC. UTC should be modified to no longer be a useful approximation to universal time. Leap seconds will be issued 3600 at a time. You all know where I stand - but there are worlds of difference between #2 and #3 as alternatives to #1. All three proposals face the same looming quadratic emergency. Again, OK so far except perhaps a quibble that it seems to be widely expected that the leap hour probably would never happen. What bothers me about this discussion is that we don't seem to be able to get beyond bouncing backwards and forwards between 1 2. As soon as anybody puts up any proposal for further detail with respect to either of these possible outcomes almost all of the response comes back in the form of arguments for the other outcome rather than sensible discussion of the idea in itself. joke Maybe for the next little while we should assume one or other outcomes each week (1 in odd ISO 8601 numbered weeks, 2 in even numbered weeks) and carry on all the discussion in that context. /joke Ed.
Re: Risks of change to UTC
On Sat 2006/01/21 10:11:04 PDT, M. Warner Losh wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL You really should read the archives of this list. We've been over this in great detail. TAI is specifically contraindicated as a time I don't think new contributors (or even old ones) should have to read the mountain of email, with its many irrelevant diversions, that has accumulated over the last 6 years - somewhat over 9MB by my count. Instead, I (re-)suggest that you (someone) write a position paper, or at least a FAQ, summarising your points. Mark Calabretta ATNF
Re: Risks of change to UTC
On Sat 2006/01/21 15:15:32 PDT, M. Warner Losh wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL Somewhere around betwee 45,000-80,000 you'll need more than one leap second a day. You should recognize this as a reductio ad absurdum argument; at that time there will be 86401 SI seconds per day - the absurdity being in continuing to pretend that there are only 86400. If at that time the number of seconds per day is officially changed to 86401 then the millenia of accumulated quadratic drift will be wiped away at once and the rate of accumulation of leap seconds reset to zero. The next step is to ask - what if we increased the official length of the day before the situation gets so far out of hand, to 86400 plus some fraction of a second? Mark Calabretta ATNF
A modest proposal
(But not the famous one from Jonathan Swift!) Perhaps standard time and frequency broadcast stations could disseminate both UTC and TAI (or TI, if that is desired). Civil time would remain tied to UTC, but TAI (or TI) would also be widely available. Consider, for instance, the audio stream from WWV and WWVH. Let the aspects of this audio stream that are more noticeable to human ears continue to convey UTC. Thus, the voice announcemnts (male voice for WWV, female voice for WWVH) would continue to announce, At the tone, HH hours, MM minutes Coordinated Universal Time. Let the ticks marking the one-second UTC epochs remain as they are: 5 cycles of 1000 Hz from WWV, six cycle of 1200 Hz from WWVH. Continue to emphasize (by double ticks) those second markers that ITU-R Recommendation TF.460 requires to be emphasized in order to convey DUT1. But let the less noticeable (to human ears, at least) 100 Hz subcarrier tone be used to convey the new TI time scale rather than UTC. LF broadcast stations should probably continue to disseminate UTC, since they are used in so many consumer wrist watches and wall clocks. If there _are_ any currently unassigned bits in the WWVB data stream (there can't be many), then those bits could be multiplexed over several cycling one-minute pages of WWVB data to convey the current value of (UTC - TAI) [or of (UTC - TI)]. We need to widely disseminate BOTH UTC (beacuse it is, and should remain, the basis of civil time) AND ALSO a more regular time scale that lacks leap seconds (e.g., TAI). -- James Maynard Salem, Oregon, USA
Re: NOT A cruel fraud!
In message: [EMAIL PROTECTED] Peter Bunclark [EMAIL PROTECTED] writes: : On Sun, 22 Jan 2006, M. Warner Losh wrote: : The short answer is that you cannot get a time feed of TAI, so the : : So isn't this one of the things we want to fix in the brave new world of : joined-up timekeeping? Distribute (very close to) TAI, keep the kernel : PLLs sweet, move leap second handling to user-space and thus make : debugging very easy, then everone can get their timescale of choice as : a f(TAI)? Yes. That's a fair summary. Warner
Re: the tail wags the dog
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Michael Sokolov) writes: : Steve Allen [EMAIL PROTECTED] wrote: : : The CGPM recommendation on the timescale everyone should use says UTC. : : UTC(insert your national time service here) is available in real time. : : TAI is the mathematical (really the political or diplomatic) entity : upon which UTC is ostensibly based, but the practical and legal : reality is the other way around. : : Has it occurred to any of you that *THIS* is the very root of the problem, : that *THIS* is what we need to change? I believe so. : Also, isn't TAI readily available in real time from GPS? (How difficult : can it be for the routine parsing the data stream from the GPS receiver : to add 19?) OK, OK, it'll be TAI(GPS) rather than true TAI, but then : your UTC is really UTC(NIST) or UTC(USNO) or UTC(PTB) or whatever rather : than true UTC. You can get an excellent approximation of TAI from GPS, assuming that you use a sane receiver... Some firmware doesn't deal well with reporting the raw, uncorrected GPS time, but many do it well. Depending on your needs, you may have to put the GPS receiver into a mode that only reports URC... Well, you get the idea. It can be done to a degree of accuracy that most people will accept, but the post-processed time scale calculations are a little better than what happens in real time. Warner
