Re: A lurker surfaces
Daniel R. Tobias wrote: It's a few seconds off from TAI, isn't it? It was synchronized to UTC in 1980 (I think), Yes. The epoch for GPS time is 1980-01-06T00:00:00 UTC, which is 1980-01-06T00:00:00 GPS time. Not having leap seconds, it effectively tracks TAI, with the equation TAI(GPS) = GPS + 19 s TAI(GPS) generally stays within about 15 ns of TAI. The GPS time signal uses a ten-bit count of weeks, which wraps every twenty years, so the raw signal is ambiguous between, for example, 1987-05-20 and 2007-01-03. They are, nevertheless, distinct points on the GPS time scale. I recall there being some plan for a new field in the navigation message that would disambiguate them. They probably should just have used TAI if they wanted a time scale without leap seconds, rather than ending up creating a different one. Would have been nice. Actually, since the only real significance of GPS time is that it's part of the signal format, they could just as well have picked an unconventional but space-efficient encoding (say, 32-bit count of seconds, wrapping every 4 Gis). I think GPS time is best viewed as an encoding of TAI(GPS). -zefram
Re: A lurker surfaces
In message [EMAIL PROTECTED], Zefram writes: Would have been nice. Actually, since the only real significance of GPS time is that it's part of the signal format, they could just as well have picked an unconventional but space-efficient encoding (say, 32-bit count of seconds, wrapping every 4 Gis). I think GPS time is best viewed as an encoding of TAI(GPS). I have been told by a person who should know better than to tell me such things that the choice of timescale in GPS is the result of unmitigated incompetence and the signal format is sheer stupidity. The fact that the UTC offset is in the Almanac instead of the Ephemeris means that almost all of the rapid response weapons cannot be used for tightly timed attacks until they have been primed with an almanac. He talked about the transmissions of the almanac being staggered between the satellites rather than in tandem, to reduce the mean-time to capture UTC-delta, but I did not find out if this was reality or plan. I guess one could use the raw-dump message to the Oncore and decode the almanac by hand to find out if this is the case. He also said that the quote in my .signature was used more often in Pentagon than he was comfortable with. Poul-Henning -- 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: A lurker surfaces
On Tue, 2 Jan 2007, Steve Allen wrote: 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. I've been reading The Measurement of Time by Audoin and Guinot, and one of the things its history of time keeping makes clear is that a lot of the improvements have been driven by cross-comparison of different measures of time. At the moment UTC requires the keepers of atomic time and astronomical time to work together, guaranteeing continued funding and employment for both :-) If we were to move to a purely atomic foundation for civil time, I wonder what effect that will have on the organizational arrangements. Will there continue to be enough cross-checks to drive the keepers of time to further improvements? Will geodesy be enough to preserve the astronomers' jobs? I usually take a technical view of things so this slightly meta way of thinking is unfamiliar to me... (Audoin and Guinot seem to favour purely atomic time.) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FAIR ISLE FAEROES: SOUTHWESTERLY BECOMING CYCLONIC THEN NORTHWESTERLY 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9. VERY ROUGH OCCASIONALLY HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OCCASIONALLY POOR.
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: 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: 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: 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: 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: 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: 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: 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: 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: 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
Re: A lurker surfaces
On Dec 30, 2006, at 17:41, Jim Palfreyman wrote: The earlier concept of rubber seconds gives me the creeps and I'm glad I wasn't old enough to know about it then! I rather like the idea, though perhaps not quite the same kind of rubber as was used. 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 would mean no nasty unusualities, and match the common intuition that a second is a fixed fraction of a day. If NTP were to serve up this sort of time, I think one's computer timekeeping would be quite stable. And of course this will work forever, long after everyone else is fretting over how to insert a leap-hour every other week, or whatever. Software should serve human needs, not the other way around. Anyone needing fixed seconds should use TAI. 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. -- Ashley Yakeley
Re: A lurker surfaces
In message: [EMAIL PROTECTED] Ashley Yakeley [EMAIL PROTECTED] writes: : Software should serve human needs, not the other : way around. Anyone needing fixed seconds should use TAI. I think this idea would be harder to implement than the current leapseconds. There are many systems that need to display UTC externally, but need to operate on a tai-like timescale internally. Having there being a sliding delta between them would be a nightmare. Warner
Re: A lurker surfaces
Ashley Yakeley [EMAIL PROTECTED] wrote: I'd like to see an elastic civil second to which SI nanoseconds are added or removed. Ditto! I have always been in favor of rubber seconds, and specifically civil second. I believe that the *CIVIL* second should have its own definition completely and totally independent of the SI second. Civil time independent of physical time would solve all problems. The scale of civil time should be defined as a continuous real number scale of *angle*, not physical time. It would solve the problem of needing to measure time intervals while at the same time synchronising with the civil calendar. Civil time interval is defined as the clock on the Kremlin tower turning by a given angle. Define one second of civil time as the hour hand turning by 30 seconds of arc. The people who complain about leap seconds screwing up their interval time computations are usually told to use TAI. They retort that they need interval time *between civil timestamps*. To me that seems like what they are really measuring as interval time is not physical interval time, but how much time has elapsed *in civil society*. Hence my idea of civil interval time that's completely decoupled from physical time and is instead defined as the turning angle of the clock on the Kremlin tower. Flame deflector up MS
Re: A lurker surfaces
Michael Sokolov scripsit: The people who complain about leap seconds screwing up their interval time computations are usually told to use TAI. They retort that they need interval time *between civil timestamps*. To me that seems like what they are really measuring as interval time is not physical interval time, but how much time has elapsed *in civil society*. I think this point is quite sound, but I don't quite see what its implications are (or why it makes rubber seconds better than other kinds of adjustments). -- John Cowan http://ccil.org/~cowan[EMAIL PROTECTED] We want more school houses and less jails; more books and less arsenals; more learning and less vice; more constant work and less crime; more leisure and less greed; more justice and less revenge; in fact, more of the opportunities to cultivate our better natures. --Samuel Gompers
Re: A lurker surfaces
On Jan 1, 2007, at 17:03, John Cowan wrote: Michael Sokolov scripsit: The people who complain about leap seconds screwing up their interval time computations are usually told to use TAI. They retort that they need interval time *between civil timestamps*. To me that seems like what they are really measuring as interval time is not physical interval time, but how much time has elapsed *in civil society*. I think this point is quite sound, but I don't quite see what its implications are (or why it makes rubber seconds better than other kinds of adjustments). One implication is that a leap second insertion is a second of real time, but zero seconds of intuitive civil time. Rubber seconds are appropriate because we have rubber days. People who need absolute time have their own timescale based on some absolute unit (the SI second), but to everyone else, the second is a fraction of the day. -- Ashley Yakeley
Re: A lurker surfaces
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] (Michael Sokolov) writes: : The people who complain about leap seconds screwing up their interval : time computations are usually told to use TAI. They retort that they : need interval time *between civil timestamps*. Actaully, interval deltas are needed, but it is in TAI time. There needs to be, in the systems I've done, a timescale without leapseconds to keep all the measurements sane. In addition, many of the systems I've done have other functions they do also, some of which need to present UTC to the user. As much of a pita that leapseconds are today, having the converion between TAI and UTC (or put another way: between GPS and UTC or LORAN and UTC) would make these systems signficantly more difficult to get correct. There's also times when our systems take in events that are timestamped using UTC time, so we need to back correlate them to TAI or whatever internal timescale we're using. Some of that is because UTC is the standard for exchanging time, part of that is because the events in question are measured in whatever timescale is present on an NTP server. : To me that seems like : what they are really measuring as interval time is not physical : interval time, but how much time has elapsed *in civil society*. Hence : my idea of civil interval time that's completely decoupled from physical : time and is instead defined as the turning angle of the clock on the : Kremlin tower. Actually, you are wrong. The intervals is in the number of pps that have happened, or fractions thereof. Civil time does intrude because that's what people use right now to know time fo day. In the systems I've done, you need to know both. The requirements, as you may have noticed, for my needs aren't that the intervals be done in TAI (we use a variant of LORAN time due to historical accident, but with a 1970 epoch), but rather that UTC and these time scales be convertable between one another. Like I've said a number of times, saying 'just use TAI' isn't viable because of the conversion issue. Using TAI (or something with the no leapsecond regualrity that TAI gives) is necessary for the algorithms to work. However, external pressures also require that some things be done in UTC time and that some of the external sources of data use UTC time and that needs to be back correlated to the internal timescale that we're using. The algorithms, btw, basically integrate frequencies of different clocks, over time, to predict phase difference. In this case, you definitely want to use an interval, and not whatever weirdnesses civil time happened to do in that interval. Using an civil time interval would introduce errors in algorithms. These algorithms are used to estimate how well the clocks are doing, but other parts of the system need to play our UTC for things like NTPD and IRIG. Warner
Re: A lurker surfaces
From: Michael Sokolov [EMAIL PROTECTED] Subject: Re: [LEAPSECS] A lurker surfaces Date: Mon, 1 Jan 2007 22:22:23 GMT Message-ID: [EMAIL PROTECTED] Ashley Yakeley [EMAIL PROTECTED] wrote: I'd like to see an elastic civil second to which SI nanoseconds are added or removed. Ditto! I have always been in favor of rubber seconds, and specifically civil second. I believe that the *CIVIL* second should have its own definition completely and totally independent of the SI second. Civil time independent of physical time would solve all problems. The scale of civil time should be defined as a continuous real number scale of *angle*, not physical time. It would solve the problem of needing to measure time intervals while at the same time synchronising with the civil calendar. Civil time interval is defined as the clock on the Kremlin tower turning by a given angle. Define one second of civil time as the hour hand turning by 30 seconds of arc. No. It does not solve all problems. It introduces a whole bunch of new problems of which I don't see any chances of swift implementations in many systems and infact there would be quite large investments involved which I don't see with other proposals. Why? Today we have a joint infrastructe for time distribution and in effect much of todays *civil* time effectively hangs of GPS and do some degree transmissions suchs as MSF, DCF77 etc. The later sources can be adjusted to rubber seconds, but doing this to the GNSS world such as GPS would be quite problematic. The NTP side of the world depends on various sources of UTC such as GPS, MSF, DCF77 etc. For that not to break we need a real-time or near real-time solution to compensate for that (using information comming from that source for security reasons). The longwave radio sources can easilly be adjusted at the source, but some of their uses still lies in frequency comparision so due care would be needed for those still using those sources for that purpose. For GPS it would most probably require additional messages for a predicted rubberization of the transmitted GPS time. This would also require the update of all GPS receivers related to legal timing relating to be able to include the correction. Another way to go around it would be to adjust all sources (including GPS) to actually transmitt rubber seconds. This would mean deeper modifications of the GNSS satellites. I don't see that happening. The last time we ran rubber seconds we could easilly device the transmitters of time with the necessary hardware and run adjustments. The problems with rubber seconds back then was that the detailed operations deviated from site to site, so two transmitters would not necessarilly work. These days we have a much more rigid system. We cannot choose arbitrarilly. UTC is the civil time and in some countries the legal time. We need it to tick in some reasnoble relation to things like the rise, noon and settlement of the sun. Rubber days by means of leap seconds or leap minutes would work. There are issues with these, mostly relating to the scheduling time obviously. Not to say that there isn't problems with leap seconds. However, for the civil use aspect, the DUTC 0.9s is not necessary. There is however a requirement to keep DUTC below some limit, so just giving up on leap seconds would be unacceptable in the long run. To avoid such things we have already corrected the calender through the Julian and Gregorian corrections. We do have TAI for usage of time intervals etc. Many systems uses TAI (or some offset of TAI) and then leap second corrections for UTC reference. The leap seconds can cause problems when jumping between TAI and UTC and which particular problem one get depends on what the goal is (i.e. if a particular UTC time is needed to a particular time difference). A scheduled leap second may arrive into the decission process later than the initial decission was taken in a system. The problem can be solved, but it complicate matters, but they do not necessarilly become impossible. There are problems relating to leap seconds. Interestingly enought, the previous scheduling rules where limited by mail transfer to all affected parties. With the new digital communication allowing us to transmitt messges to any part of the globe within a few seconds, we seems to have a need for a longer scheduling time. But sure, a longer scheduling time could work. I think there is no real solution outside of the leap second (or possibly leap minute) world. Rubber seconds has too many issues for it to be useable. Abandoning leap second issuing doesn't fullfill the civil useage in long term. We can work with the ways we predict and schedule leap seconds. The noise process however prohibit us from setting up strict rules such as the Gregorian date rules for leap days, those will actually have to be corrected too eventually. So, for civil usage, I have yeat to hear a better proposal than leap seconds. There is room
Re: A lurker surfaces
Ashley Yakeley scripsit: Rubber seconds are appropriate because we have rubber days. People who need absolute time have their own timescale based on some absolute unit (the SI second), but to everyone else, the second is a fraction of the day. Well, okay. Does the rubberiness go down all the way? Is a civil nanosecond one-billionth of a civil second, then? If so, how do we build clocks that measure these intervals? -- One art / There is John Cowan [EMAIL PROTECTED] No less / No more http://www.ccil.org/~cowan All things / To do With sparks / Galore -- Douglas Hofstadter
Re: A lurker surfaces
On Tue 2007-01-02T01:48:26 -0500, John Cowan hath writ: Well, okay. Does the rubberiness go down all the way? Is a civil nanosecond one-billionth of a civil second, then? If so, how do we build clocks that measure these intervals? Let's not. Let's continue the valid and agreeable notion of transmitting seconds and frequencies based on a coordinate time scale tied to the ITRS at a specified depth in the gravitational+rotational+tidal potential. The best practical implementation of such is undeniably the estimation given by TAI. 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. And let's create an interface better than POSIX time_t which allows those applications which need precise time to do a good job at it. -- 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: A lurker surfaces
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Rob Seaman writes: Jim Palfreyman wrote: Just a reminder that UTC has no - none - nada - discontinuities. Various computer mis-implementations may, but the standard is very carefully constructed to avoid spring-forward or fall-back gaps or do- overs. Rob, If you feel uncomfortable with calling leapseconds discontinuities, then we can use the term arrhythmia instead. If we assume that every month has 30 days and obtain a day number by multiplying the month number by 30 and adding the day in month (call this the SDN - Silly Day Number) and then look at SDN-MJD (modified Julian day number) we would see discontinuities. The only way to see discontinuities in UTC-TAI is by making an equally silly assumption in numbering the seconds of UTC: assuming all UTC minutes are 60 seconds or, equivalently, all UTC days are 86 400 seconds. The unfortunate thing is that people actually do think of it this way. E.g.: http://hpiers.obspm.fr/eop-pc/earthor/utc/TAI-UTC_tab.html The whole idea of the expression UTC-TAI being meaningful and evaluating to a number of seconds is a convenient but rather sloppy shorthand. Any strongly typed programming language ought to give a type error on that expression. UTC times of day are variable radix - in just the same way as days and months are in the Gregorian calendar. Except, of course, that the Gregorian calendar is fixed and completely predicable. I have an awful lot of sympathy for the idea of making leap seconds predictable over longer periods, even if it risks UTC-UT1 becoming larger than at present allowed. Ed.
Re: A lurker surfaces
On Sun 2006-12-31T07:59:35 +, Poul-Henning Kamp hath writ: Rob, If you feel uncomfortable with calling leapseconds discontinuities, then we can use the term arrhythmia instead. The point of my allegory about unplanned pregnancies is that all practically available time scales have arrhythmias. Almost everything has jumps at some point during power on self test, and the national time bureaus (and the GPS almanac) publish their current estimate of their deviation from regularity. If you can handle leap seconds, then you can handle reality. The decision made 37 years ago was that the reality of most systems didn't/couldn't care about seconds, and that's the part that now is getting scrutiny. What tweaks me is that I get the impression that a lot of folks are perfectly willing to accept those irregularities and to let Dave Mills diddle with the rates of their system clocks so long as they never have to admit the existence of a named leap second. It's as if everything is okay so long as the baby never comes to term -- everyone can live in denial about those things going on behind the scenes -- but as soon as the county recorder gets that birth certificate with Mr. Astronomer named as father the social order of the world breaks down. I see this as a form of denial. Almost all applications may be capable of tolerating the level of irregularity in the currently practically available time scales, but they are irregular. What happens in a world with terabit per second information streams coming over fibers from sources whose clocks, even if they are ion-trap clocks (especially if so), are different tidal potentials that vary diurnally? (Of course the glib answer is that if the optical fiber engineers do manage to notice this first then they will win the Nobel prize just as surely as Penzias and Wilson did after they found that cleaning pigeon shit out of their microwave horns did not manage to make the background noise go away.) What happens in a world where systems begin to be sensitive to the effective leap microseconds or variations in length of seconds which happen even if Dave Mills is conditioning their clocks? It's my expectation that if all systems are allowed to deny the reality of precision time keeping we will eventually find ourselves living in a timekeeping world that resembles C.M. Kornbluth's story The Marching Morons. -- 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: A lurker surfaces
On Sun, 31 Dec 2006, John Cowan wrote: However, it's clear that UTC does not contain the sort of jumps that LCT does, where a single broken-down time may represent two different UTC seconds. Not if you include the timezone offset in the representation. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ THAMES DOVER WIGHT PORTLAND PLYMOUTH BISCAY: SOUTHWEST VEERING WEST 6 TO GALE 8, INCREASING 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. ROUGH OR VERY ROUGH BUT HIGH IN PLYMOUTH AND BISCAY. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.
Re: A lurker surfaces
Rob Seaman wrote: Just a reminder that UTC has no - none - nada - discontinuities. I concur, and so I prefer to say that UTC has _irregularities_. The rest of what Jim Palfreyman said applies to these irregularities: they must occur frequently so that the method of handling them is implemented and well tested. -zefram
Re: A lurker surfaces
In message: [EMAIL PROTECTED] John Cowan [EMAIL PROTECTED] writes: : Tony Finch scripsit: : On Sun, 31 Dec 2006, John Cowan wrote: : : However, it's clear that UTC does not contain the sort of jumps : that LCT does, where a single broken-down time may represent : two different UTC seconds. : : Not if you include the timezone offset in the representation. : : Quite so. Or alternatively a standard/daylight flag. The point is, : people usually don't. This is the leapsecond problem in a nutshell: While it is possible to keep enough information around in the representation of time, most people opt not to do so. It complicates the representation of time, and is one (or more) pieces of information that need to be carried around, mostly just to handle weird edge cases. Sure, you can do it, and some people try. However, there's no standardized way to do so, and people re-invent it wrong over and over again. Another poster I think was right: ntpd (and the underlying OS) hides a lot of these sins. Either by just twitterpating at the leapsecond in some way (time stands still, time jumps back a little, etc), or for a period of time around the leapsecond (by sticking its fingers in its ears, singing lalala and changing the size of a second to get through it a millisecond at a time). Warner
Re: A lurker surfaces
Poul-Henning Kamp wrote: Rob, If you feel uncomfortable with calling leapseconds discontinuities, then we can use the term arrhythmia instead. Which raises the question of why projects requiring an interval time scale lacking in such arrhythmias would have selected UTC in the first place. And why timekeepers who understand these issues would focus on remediating (i.e., eviscerating) UTC as the cure. Astronomers are among the power users for interval time as well as time-of-day. Helioseismologists (http://gong.nso.edu) needed an interval timescale that would be even tempered over years or even decades (a solar cycle is eleven years - the magnetic field flips at solar max, so a complete sample would require 22 years) - so they selected GPS, not UTC. But actually, I think we should call leap seconds what they are - intercalary events. My wife works at the Arizona-Sonora Desert Museum. We have family visiting and decided to spend the day at the museum - a good way to end a year. I especially recommend the raptor free flight program - the ferruginous hawk is especially impressive. My point is that a javelina is not a pig, a coatimundi is not a raccoon, and a ringtail cat is not a cat. A kangaroo rat is, of course, neither. And a leap second is a not a discontinuity. Imprecision in terminology leads to poor decision making. Rob
Re: A lurker surfaces
In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : Poul-Henning Kamp wrote: : : Rob, If you feel uncomfortable with calling leapseconds : discontinuities, then we can use the term arrhythmia instead. : : Which raises the question of why projects requiring an interval time : scale lacking in such arrhythmias would have selected UTC in the : first place. The real world often times requires both kinds of time keeping, with correlation back and forth between all the timescales. The customers want to deal with times in UTC. To get an effective, high precision time system, you need to count seconds in a sane way (UTC isn't a sane way for this purpose) so some conversion between this count and UTC is needed. The problem is that most interesting systems have a need to do things based on UTC time of day, as well as in a time scale that has none of the complications of the unpredictable UTC implementation we have today. So you can't just 'pick one' because real-world systems need to use different ones for different things, and they also need to translates events from one timescale to events in the other timescale. Let me give you a concrete example. Let us say we are measuring a number of atomic clocks against one another. We get the measurements and those measurements are in a monotonic timescale that is defined as PPS's from some epoch (or number of 5MHz or 10MHz ticks from some arbitrary epoch). We get data from GPS, which has a similar timescale. We compute the clock states and deside that we need to steer one of the clocks. These algoritmns are very much elapsed time sorts of deals. So we schedule a time to steer it, and then note the time when we are done steering it. Since we cannot easily get the GPS or timer times without interfereing with the operations of those subsystems (maybe because the steering system and GPS system are on dufferent cpus), we get the system time when the steer starts and when the clock tells us the steer is complete (since a steer isn't an instantaneous event). Since this system also is an ntpd server, that system time is in UTC. Now we have to convert UTC into the internal timescale so that the algorithms know when the steer happened and can take that into account for their next round of measurments and decision making. To make this all work out well, one has to have perfect leap second knowledge and all the special case code you have for dealing with the arrhythmia of a leap second has to work perfectly. Anything that can be dobe to make things more perdictable helps out quite a bit... Warner
Re: A lurker surfaces
Jim Palfreyman wrote: With my time hat on, having time that is discontinuous pains me. It doesn't make sense in my heart. But at least these discontinuities are in whole seconds. Any discontinuities must be regularly done. So they are part of all computer systems and are tested and used all the time. Don't let them build for a decade - that is bad bad news. Just a reminder that UTC has no - none - nada - discontinuities. Various computer mis-implementations may, but the standard is very carefully constructed to avoid spring-forward or fall-back gaps or do- overs. This is just one of many flaws of the notion of leap hours. A leap hour (like a leap second or leap day) is an extra intercalary temporal unit inserted into the continuous flow of time. A leap hour is NOT an unmatched fall back do-over - the day in question would have 25 regular, ordinary, permanent, unique hours - and the extra hour would occur contemporaneously worldwide. It would not involve an easy floating 2 am Sunday local clock reset. So, for example, if the leap hour is 2606-12-31, 24:00:00 to 24:59:59 UT, it would fall BETWEEN 18:59:59 and 19:00:00 EST, just like a leap second today is 23:59:60 UT or 18:59:60 EST, also falling between 18:59:59 and 19:00:00. In each time zone in turn, the leap hour would fall between different otherwise sequential clock ticks - a non- issue with a leap second, not so easy to ignore with a leap hour. Still not a discontinuity, but certainly a real pain for anyone who is trying to keep the events of the day straight. More than likely, the hour would be labeled the same worldwide, so the EST clock would run 18:59:58, 18:59:59, 24:00:00, 24:00:01, ..., 24:59:58, 24:59:59, 19:00:00, 19:00:01, ... Rob
Re: A lurker surfaces
In message: [EMAIL PROTECTED] Rob Seaman [EMAIL PROTECTED] writes: : Just a reminder that UTC has no - none - nada - discontinuities. At the very least, the TAI-UTC difference is discontinuous with jumps at the leap seconds. One could easily suggest that 'UTC has discontinuities' really is a shorthand way of saying this. One could also call them irregularities, like the time scale is constipated, as well. And the variable radix seems to be to be a crude way to define away the problem. You never know, unless you look it up in a table, when to do the variation in the radix. : Various computer mis-implementations may, but the standard is very : carefully constructed to avoid spring-forward or fall-back gaps or do- : overs. Well, if you count the variable radix notation as being 'continuous' then maybe you are right. However, you never know when the radix is variable, hence the assertion on many people's part that UTC is discontinuous. Warner
