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?

  • 1
    $\begingroup$ From the docs for AstronomicalData[]: "Corrections for atmospheric refraction and light time delay are not included." $\endgroup$ – J. M. will be back soon Oct 22 '12 at 23:30

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:


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:

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]


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}

  • $\begingroup$ When I run AstronomicalData["Sun", {"Altitude", {2008, 1, 21, 12, 0, 0}, {53, 0}}] I get ~ -23. What does that mean? $\endgroup$ – Mr.Wizard Oct 22 '12 at 22:20
  • 1
    $\begingroup$ @mr.wizard It means you're on version 7 ;-) $\endgroup$ – Sjoerd C. de Vries Oct 22 '12 at 22:23
  • 1
    $\begingroup$ @Mr.Wizard but seriously, try setting a different TimeZone. I seem to rembember now, btw, that they removed a bug in the TimeZone calculations, so that may explain the difference between the results of 2008 and now. Will check that tomorrow; my iPad doesn't run Mathematica (yet). $\endgroup$ – Sjoerd C. de Vries Oct 22 '12 at 22:27
  • $\begingroup$ @raxacoricofallapatorius Please see my update. It's less a problem then I made you believe. Please also consider removing your comment in this light. $\endgroup$ – Sjoerd C. de Vries Oct 23 '12 at 13:24
  • $\begingroup$ Good catch! Done. I worry though now that I have to go back through all my code and review where TZ is required. $\endgroup$ – orome Oct 23 '12 at 13:25

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:

AstronomicalData["Moon", "NextRiseTime"]

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:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.