Re: Introduction of long term scheduling
From: Tony Finch [EMAIL PROTECTED] Subject: Re: [LEAPSECS] Introduction of long term scheduling Date: Wed, 3 Jan 2007 17:38:35 + Message-ID: [EMAIL PROTECTED] On Wed, 3 Jan 2007, Magnus Danielson wrote: Assuming you have corrected for another gravitational field, yes. The current SI second indirectly assumes a certain gravitational force, we is assumed to be at sea level whatever level that is. Wrong. The SI second is independent of your reference frame, and is defined according to Einstein's principle of equivalence. Good point. Thanks for reminding me. What *does* depend on the gravitational potential at the geoid is TAI (and TT), since a timescale (unlike a fundamental unit) is relative to a reference frame. When comparing two realizations of an SI second, compensation of the difference in the reference frame needs to be done. To build up TAI, difference in gravitational force do need to be compensated out. We still depend on geophysics to some degree. Note that the standard relativistic transformations between TT, TCG, and TCB is (since 2000) independent of the geoid. So although the realization of these timescales is dependent on geophysics (because the atomic clocks they are ultimately based on are sited on the planet) the mathematical models try to avoid it. Naturally. Cheers, Magnus
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
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
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: Introduction of long term scheduling
From: Poul-Henning Kamp [EMAIL PROTECTED] Subject: Re: [LEAPSECS] Introduction of long term scheduling Date: Mon, 1 Jan 2007 19:29:19 + Message-ID: [EMAIL PROTECTED] Poul-Henning, In message [EMAIL PROTECTED], Steve Allen writes: McCarthy pretty much answered this question in 2001 as I reiterate here http://www.ucolick.org/~sla/leapsecs/McCarthy.html What exactly is the Y axis on this graph ? Unless you have a subtle point, I interprent it to be in seconds even if they are incorrectly indicated (s or seconds instead of sec would have been correct). If you have subtle point, I'd love to hear it. Cheers, Magnus
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 for
Re: what time is it, legally?
From: Peter Bunclark [EMAIL PROTECTED] Subject: Re: [LEAPSECS] what time is it, legally? Date: Wed, 13 Dec 2006 10:05:00 + Message-ID: [EMAIL PROTECTED] Rob, On Wed, 13 Dec 2006, Ed Davies wrote: Rob Seaman wrote: I'm given to wonder how much of the friction on this mailing list is simply due to the shortcomings in the technology that implements it. I've appended a message I sent in August with four plots attached. Can someone tell me whether it is readable now or was successfully delivered back then? I rummaged around on the list archive and on archives accessibly via google and find no copy of this message that survived the communications medium. In Thunderbird on Ubuntu Linux it looked fine in both your original post and the repeat you attached - so any problems are down to the reader and not the transmission, I think. Ed. Fine on Solaris 10. I concurr, it worked nice on Debian Linux using Mew in Emacs. I had nice graphs and everything. You need to look elsewere (i.e. more locally) to find the fault. Cheers, Magnus
Re: what time is it, legally?
From: Steve Allen [EMAIL PROTECTED] Subject: [LEAPSECS] what time is it, legally? Date: Mon, 11 Dec 2006 20:45:58 -0800 Message-ID: [EMAIL PROTECTED] This history is apparently not lost to folks at NIST, for the US senate continues to consider legislation which would explicitly rewrite US legal time to be based on UTC (as locally interpreted) rather than Greenwich mean solar time. The most recent incarnation of the bill appeared in September as S3936, and section 1406 contains the text to make the change. See at http://thomas.loc.gov/cgi-bin/query/z?c109:S.3936.PCS: (and note the trailing colon in the URL). The bill has a lot of cosponsors as seen in the links on Thomas. Clearly the passage of this bill would short circuit a litigation process which the Jenni Parrish document shows to have lasted for most of a lifetime. Sounds like a good thing. Here in Sweden, Swedish Normal Time is by law defined to be UTC + 1h. Both UTC and BIPM is explicitly mentioned in the law (SFS 1979:988). Swedish summertime is a little bit fuzzier, but UTC + 2h is a valid interpretation. There is 8 NTP servers being under the control of the national metrological institute SP. Those servers traces back to the national laboratory, redundant, has backup power for as long as we care. However, there is actually no legal path to get traceable time. It is not only necessary to have legal time defined as UTC, you also need the legal tools which enables legal supported (and required) traceability, so that definition actually means something. When reading up on the issue and talking to the national accreditation boards cheif lawyer, I was not only supprised about the loophole, but the view the accreditation board feeling not empowered to address the issue besides for customer concerns. Sigh. Let's just say that I was less than happy with the situation. Work is under way to remedy that issue. Now, how is the situation elsewhere? Is the legal definition followed up with the legal tools to also do traceability of time (and not just SI second)? Cheers, Magnus
