On Fri, 31 Oct 2008 10:06:17 -0500, Field, Alan C. wrote:
>Maybe leap seconds won't be an issue:
>
>http://tycho.usno.navy.mil/leap_second_poll.html
>
The referenced document:
Linkname: Memorandum and white paper
URL:
http://tycho.usno.navy.mil/Discontinuance_of_Leap_Second_Adjustments.pdf
... mentions 3 requirements:
1) Atomic accuracy
2) Continuity
3) Agreement with earth's rotation.
IAT satisfies (1) and (2) but not (3).
UTC satisfies (1) and (3) but not (2).
UT1 satisfies (2) and (3) but not (1).
It's logically impossible to satisfy all three at once. Of the
three approaches, I see the least need for UTC. I'd favor
abolishing UTC rather than freezing it and abolishing the
sporadic insertion of leap seconds.
>Leap seconds are a PITA. I'd like to reflect your question
>to IBM: What customers' business needs was IBM addressing
>in choosing to run the TOD clock on IAT (minus ten seconds),
>rather than on UT1 which would avoid the discontinuities
>of leap seconds.
In that case, the [E]TOD clock should run on UT1, with system
calls available to convert to IAT in the past and for as far
in the future as the offset can be known with satisfactory
accuracy.
How about a chordwise rather than a stepwise approximation to
UT1, retaining the current 4-month advance notification of
parameter updates, where there would be 2 parameters, slope
and offset, rather than the current offset only? IBM could
even do this unilaterally for [E]TOD purposes.
The earth's equatorial rotational velocity is about 500 m/sec.
The guaranteed maximum UT1-UTC offset is 0.9 seconds. So
using UTC for geolocation could result in an error of 400
meters; inferior to GPS accuracy. What use UTC?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
