In message <E381FDF7-1C72-4218-89E2-52C14922939C_at_noao.edu>, Rob Seaman writes:
>> The whole point of the 24:60:60 notation is to match up with the
>> day. In order to do that all civil time scales have always had
>> leaps or seconds of non-uniform length or both. Dynamical time and
>> atomic time have no such concept and should always have been
>> communicated as a decimal count of elapsed seconds.
>>
>> [1] Confusing the one entity with the other in the original
>> definition of Ephemeris Time was perhaps the biggest timekeeping
>> mistake ever made by astronomers.
[1] no opinion.
>> [2] Not following the suggestion to define the cesium-based,
>> Ephemeris-Time-inspired unit of duration as a new unit called the
>> Essen was perhaps the biggest timekeeping mistake ever made by
>> physicists.
[2] That would have taken a rewriting of all physics textbooks, and
a lot of work on the meter convention.
There is nothing in the meter convention that would prevent having
two units for time, but I think it would be hard to sell the concept
in terms of science: the Second is an invariant (to the best of
our ability) fundamental unit of measurement whereas finding out
what the Earth does is registrative geophysics.
Therefore, if the sale were made, it would probably result in a
rename of the earth-locked second to a "Copernicus" or "Keppler"
("Newton" is already taken) and the atomic second would remain
a "Second".
>> [3] Allowing civilian entities to believe that the broadcast
>> time signals originally intended for navigation could also be used
>> for setting civil time was perhaps the biggest timekeeping mistake
>> ever made by the CCIR (now ITU-R) and all the national time services.
[3] This may be true, but given the role science plays in modern
society, it is not a defensible position in practice, in particular
not with the GPS infestation.
I would personally add a fourth mistake:
[4] Not realizing that for a future space-faring race, time needs
to be invariant of space-time, and predictable for long stretches
of time, but we seem to not be ready for that yet.
>For any time scale to ever be considered as a candidate for replacing
>UTC, its rate must approximate UTC's to within milliseconds per day
>at any given epoch.
I think you overlook that nobody (but you ?) are talking about
replacing UTC.
The rest of us, and the proposal in front of ITU-R is about changing
the UT1-UTC tolerance to one hour.
We can agree or disagree about the "leap-hour" concept and text in
the proposal USA have submitted, but in the end it doesn't matter
what we think: The scientists who will have to deal with that
leap-hour has not even had their grand-parents born yet and they
will have plenty of time to sort the details out before it is
relevant.
>So, what steps might we take to correct these mistakes made by the
>astronomers, physicists and timekeepers?
>
>1) Recognize that interval time (TAI) and solar time (UTn) are both
>necessary. (Please don't make me explain it again.)
It follows from [3] above that this has to be:
1) Recognize that interval time (TAI), civil time (UTC) and
solar time (UTn) are all necessary and have different constraints
imposed by their usergroups.
There is neither proof nor hard data at this time to support the
hypothesis that identity exists between solar time and civil time.
If as a matter of course we find out later that such an identity
exists, then fine, but at this time there is a lot of contrary
evidence to overcome.
Also note that any one of these names or definitions can be changed,
it is only a matter of inconvenience and cost, so let us not argue
about the names: they are just labels.
>2) Reserve sexigesimal notation for civil (solar) time. TAI and
>similar unsegmented time scales should always be communicated as
>elapsed seconds. Choice of epoch and numeric representation should
>be interesting debates. Surely I'm not alone in wanting to have
>interesting debates again?
You're rushing things a bit here with your solar == civil assumption.
(I will leave TAI and Solar time to their respective user communities.)
It is a requirement that civil time have a predictable enumeration
so far into the future that computing systems can be deployed without
needing metadata updates.
I can live with both leap seconds, leap minutes and leap hours
(although I won't get the chance), as long as we know with a decent
warning when they will happen.
The predictable enumeration needs to go so far into the future that
computing systems will be "born" with the data relevant for their
lifetime.
My personal opinion is that 50 years seems right, 20 years might
be livable.
So one feasible option is to predetermine all leapseconds (or
leap minutes ?) for the next 50 years in advance.
That means an UT1-UTC difference that could go as high as 20-30
seconds but it is still locked and bounded (by our knowledge of
geophysics, admittedly, but bounded nontheless).
>3) Clarify the relationship between the civil second and the SI
>second. It may be too late to define a new unit of duration -
>whether Essen or Fressen - or perhaps it isn't. In any event, there
>are 86400 seconds per solar day, and that usage of the word "second"
>clearly differs from the SI unit which happens to have the same
>name. What are we going to do about it? (Certainly the ITU proposal
>does not address such issues.)
I think redefining the length of the SI second is a folly. Like
the kilogram may not be the best definition, it is the one we have
used for a long time, and the cost of redefining to a different
size would just not pay off under any conceiveable scenario.
It is also worth noting that while the meter was originally defined
in ratio to the circumference of the Earth, subsequent improvements
to our measurement of and changes in the circumference of the Earth
has not caused us to adjust the length of the meter.
The fact that the SI second is the best defined and most measurable
of all our SI units, and that we have defined several other
measurements, including the meter, in terms of the SI second should
not be overlooked.
I would say that the SI second and TAI definitions are the most
given facts in all this.
>4) UTC performs the neat trick of conveying BOTH TAI and an estimate
>of UT1 in one convenient package. If we are no longer going to do
>this, what is the alternative? Shall both TAI and UT1 be separately
>conveyed? Shall one be conveyed and the other calculated from it
>using standard algorithms incorporated into, for instance, consumer
>electronics? This simply must be clarified before a functioning
>system for conveying both is dismantled.
But this is already a fact...
The only question is how good an estimate it will be in the future.
In my mind, the only question we have to settle is the UT1-UTC
tolerance.
The proposal from USA sets it to one hour and leave the implementation
details to decendants who are not even likely to be able to read
the language we write today.
But as I said above, I can live with a more stringent tolerance,
as long as we get a predictable enumeration for the forseeable
future.
So, in the interest of compromise: What UT1-UTC tolerance can
astronomers live with ? (I would personally think that 1 second
was already too much and that DUT1 corrections would be needed
pretty much all the time already ?)
How about we go to leap minutes, scheduled 50 years in advance,
would that work for you ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Thu Aug 04 2005 - 00:27:36 PDT