Re: [LEAPSECS] A lurker surfaces

From: Magnus Danielson <magnus_at_rubidium.dyndns.org>
Date: Tue, 02 Jan 2007 07:39:59 +0100 (CET)

From: Michael Sokolov <msokolov_at_IVAN.HARHAN.ORG>
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Mon, 1 Jan 2007 22:22:23 GMT
Message-ID: <0701012222.AA10926_at_ivan.Harhan.ORG>

> Ashley Yakeley <ashley_at_SEMANTIC.ORG> 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
Received on Mon Jan 01 2007 - 22:40:30 PST