Re: [LEAPSECS] A lurker surfaces
From: Ashley Yakeley <ashley_at_semantic.org>
Subject: Re: [LEAPSECS] A lurker surfaces
Date: Tue, 02 Jan 2007 15:21:14 -0800
Message-ID: <459AE8EA.7010007_at_semantic.org>
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
Received on Tue Jan 02 2007 - 16:15:08 PST
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:56 PDT