How is AstronomicalData interpreting its date arguments?

Question

It is easy to confirm that the AstronomicalData is not interpreting its arguments as UTC (or "GMT", which is, in any case, ambiguous) dates by verifying that the changes in the data it reports do not show a jump over a leap second:

ListPlot[
    AstronomicalData["Pluto", {"Azimuth", #, {51.4773673, 0.00000000}}, TimeZone -> 0] & 
    /@ (DateList[{2012, 6, 30, 23, 59, N[58 + 2/3*#]}] & /@ Range[0, 6])]

What timekeeping system is AstronomicalData assuming its date argument corresponds to? It could be any of the "smoothly flowing" timekeeping systems. Either one of the uniform ones, TAI, TT/TDT, or GPS, each of which differs from UTC by a different amount beyond the cumulative number of leap seconds to date (0s, 32.184s, and -19s, respectively); or, more likely, UT1.

Answer 1

Leap seconds are added by international agreement so that UTC time functions keep the earth at the same point in its orbit about the sun by calendar time during the year. The AstronomicalData function appears not to be terribly well documented. Here is an answer I got from "Premier Support," which is not terribly helpful:

Questions and comments: I need more information on the specification of data supplied by: AstronomicalData["Sun",{"Altitude" ,.....}] and AstronomicalData["Sun",{"Azimuth" ,.....}] These are topocentric coordinates, but do not take altitude on the earth coordinate. Should I assume 0 altitude? Is the data corrected for refraction? What is the source of the data? What is the accuracy?

---

Hello,

AstronomicalData does not provide corrections for refractions and light-travel. The altitude is taken to be 0 and the datum is the standard ellipsoid model used in GPS coordinates.

After talking with the developers, it seems defining the accuracy of these calculations can be very complicated. We try to communicate the accuracy by the number of accurate digits in the results returned from AstronomicalData. To find this, run the command Precision and Accuracy on the output of these functions.

The data for this comes from some calculations taken from the source data listed on the AstronomicalData source website:

http://reference.wolfram.com/mathematica/note/AstronomicalDataSourceInforma tion.html

Sincerely,

Sean Clarke Technical Support Wolfram Research, Inc. http://support.wolfram.com

For solar positioning, I have found the data provided less accurate than the SPA: http://rredc.nrel.gov/solar/codesandalgorithms/spa/ I have a version of this translated into Mathematica if there is a place to post it.

Answer 2

(Not an answer...)

Wolfram only knows exactly how these things are calculated now. I have a book dating from the 1970s (Practical Astronomy by Peter Duffett-Smith) that says this:

Astronomers use Ephemeris Time, which has been chosen to agree as nearly as possible with the measure of universal time... In almost every case we can take ET = UT = GMT without noticing the difference. Only when calculating the motion of the moon, and predicting eclipses, will it pay us to take account of the difference between ET and UT. In January 1980 this difference was about 51 seconds.

Although more recent systems of time measurement (TDB, TT, TCB, etc) are more carefully defined and accurate - see Steve Allen's page here, which provides way more information than you probably need, the more relevant question is "How accurate are the calculations anyway?". You probably want to know how the calculations are made (eg are they including corrections for precession, evection, variation, refraction, the effect of Jupiter on the moon's orbit, and so on), and what errors are to be expected. Then you can add this error margin to the estimated times.