# How is AstronomicalData interpreting its date arguments?

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.

-

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:

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.

-
Remarkably, Wolfram's "Premier" support has been unable to answer this question. I've received similar evasive (actually, irrelevant) answers from them. I can only conclude that they have no idea how their own API works. –  raxacoricofallapatorius Jan 6 at 4:57
I would be interested in your SPA implementation. Would you be willing to share? –  Markus Roellig Apr 6 at 9:35
"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." ...and that's where $\Delta T$ comes in... –  Ｊ. Ｍ. Nov 23 '12 at 16:01
@J.M.: The "only" is a bit misleading. This list should also include all daily motions — i.e. the horizontal coordinates of anything. For me, right now, for example, the azimuth of the moon could be half a diameter off if the difference between "Wolfram Time" and UTC is on the order of the current $\Delta T$ of about 66s. Also the issue here isn't about the fine points of $\Delta T$ (UT1-UTC) but the "bulk" of it: the accumulated leap seconds, TAI-UTC, plus some (possible) additional offset. –  raxacoricofallapatorius Nov 23 '12 at 22:05