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