What do AstronomicalData's “SetTime” and “RiseTime” values refer to?

Question

What astronomical event do AstronomicalData's "NextRiseTime", "NextSetTime", "LastSetTime", and "LastRiseTime" values refer to? Are these times that the geometric centers of the objects in question cross the horizon, or their outer limbs; do they take into account refraction, or do they refer to the crossing of the geometric horizon?

Answer 1

A couple of years ago I was in an email conversation about this topic with Jeff Bryant, a WRI employee. He was not directly responsible for AstronomicalData, but he told me that Mathematica did not correct for atmospheric refraction. Good to know, as the refraction at the horizon is about the same size as the sun itself (both in degrees).

At that time I was examining the accuracy of AstronomicalData's sun position and found it wanting. I compared the output of various sun position calculators on the net with this Mathematica call:

AstronomicalData["Sun", {"Altitude", {2008, 1, 21, 12, 0, 0}, {53, 0}}]

As recorded in my email of December 2008 the output was:

15.37414

Four different sun calculators gave a value close to 17 deg as answer, so more than a degree higher than MMA's answer. I tried all four sites again while writing this answer and found three still running at the moment:

• http://aa.usno.navy.mil/ (17 deg)
• http://curricular.providence.edu/~rgoldstein/misc/sungraph.htm (17 deg)
• http://www.esrl.noaa.gov/gmd/grad/solcalc/azel.html (17.03 deg)

At that time there was a problem with the TimeZone setting which since then has been repaired. For that call you need to specifically mention the timezone for which you want the report to be made, otherwise it's going to use your own:

AstronomicalData["Sun", {"Altitude", {2008, 1, 21, 12, 0, 0}, {53, 0}}, TimeZone -> 0]

16.97713

The result seems to match the others very well. But the time zone use is a bit unexpected of course. Why would you want to specify the time zone if you already have specified the geographical location in lat longs?

The sun position calculation was also relatively slow. As an alternative I did a straight (and I mean really, ugly straight) totally unoptimized translation in Mathematica of a VBA translation of a Javascript sun position calculator which happened to be about 20 times faster. Both are from US government servers and the files should be in the public domain.

You can get my Mathematica translation here. I have a hunch it should be fairly easy to accelerate it considerably.

The code uses atmospheric refraction and indeed, if we see the difference at sunset between its altitude and MMA's, it's about half a degree as it should:

solarposition[53, 0, 2008, 1, 21, 8, 3, 0, 0, 0]

{123.9129444, 0.09095273097}

AstronomicalData["Sun", {#, {2008, 1, 21, 8, 3, 0}, {53, 0}},TimeZone -> 0] & 
   /@ {"Azimuth", "Altitude"}

{123.80512, -0.53386}

Answer 2

A bit of spelunking reveals that AstronomicalData delegates the calculation of those properties to the function PlanetaryAstronomy`Private`RiseSetsX. You can verify this by evaluating:

On[PlanetaryAstronomy`Private`RiseSetsX]
AstronomicalData["Moon", "NextRiseTime"]
Off[PlanetaryAstronomy`Private`RiseSetsX]

My impression is that it is performing a purely geometric calculation involving only the object center, but you can judge for yourself by looking at the definition of that function and its main helper:

DownValues[PlanetaryAstronomy`Private`RiseSetsX]
DownValues[PlanetaryAstronomy`Private`SlowMovingRiseTime]