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 improvements in it, but these days I see no real solution outside of it. I have not made any conciderations relating to astronomical requirements. I think there is good insight and voices for that already here. Instead I try to consider "civil" time. In the end balance, there are a whole range of different requirements which goes into this. Also, altought it is not easy, the joint infrastructure for TAI and UTC (and other similar time scales) is both for everyones benefit and these days also a necessity (due to security reasons) and thus we need to be able to make these different sources directly comparable. So the real question is, how do we make the leap second mechanism better? Cheers, Magnus