On JPL Horizons website, I'm using the following query to get vector state for Earth:


I'm getting two values for 'x', which I guess make perfect sense, being in km:

X =-1.085163786984627E+08
X =-1.103097877035814E+08

I'm trying to have the same query in Python, using jplhorizons from astroquery library, like this:

from astroquery.jplhorizons import Horizons
from datetime import datetime, timedelta
today = datetime.now()
yesterday = today - timedelta(days=1)
obj_earth = Horizons(id='3', location='0', epochs={'start':str(yesterday), 'stop':str(today),'step':'1d'})

Running this code, I get the following output:


The values are apparently in AU, but honestly, they make no sense to me. Shouldn't I get the exact same values running this through web Horizons' interface and through the script --even if the values are in different units?

  • $\begingroup$ Not sure why you aren't defining today and yesterday in the Python code as a specific datetime values matching your web query rather than the ever-changing .now()... ? Am I missing something ? $\endgroup$ Commented Feb 6, 2023 at 17:56
  • $\begingroup$ No specific reason. Not a great choice, I know. I changed them to: today = '2023-02-07' yesterday = '2023-02-06' I'm getting wildly different values for x this way, and I still don't understand what's happening, why the values are so small. $\endgroup$
    – Claudiu
    Commented Feb 6, 2023 at 18:01
  • $\begingroup$ I suspect a reference frame difference but wanted to check the difference in the time specification wasn't significant before investigating since using an incorrect/different time system (TDB vs UTC) often leads to differences (but not this large) $\endgroup$ Commented Feb 6, 2023 at 18:06
  • $\begingroup$ The x values returned by the Python script just don't feel AU. Even if it says it's in AU. $\endgroup$
    – Claudiu
    Commented Feb 6, 2023 at 18:10
  • $\begingroup$ It's pretty easy to use the Horizons file API. Or you can use the GET-based API to send a query in a URL. Query demo. I have several examples on this site which use the file API in Python, but I'll post a minimal example in my next comment. $\endgroup$
    – PM 2Ring
    Commented Feb 7, 2023 at 1:00

1 Answer 1


The issue is with differences in how the defaults behave between the code and the website. In the code version of the API id=3 gives the Earth-Moon Barycenter (as opposed to id=399 which is the Earth itself; not sure which is wanted but it's not the most significant problem). The major problem is that location=0 in the Python code produces the position of Greenwich Observatory relative to the geocenter, which is why the numbers are so small (~2850 km).

To get the desired position of the Earth relative to the Solar System Barycenter requires using location='500@0' in the code (I also used astropy.units to do the conversion to km):

from astroquery.jplhorizons import Horizons
import astropy.units as u
from datetime import datetime, timedelta
today = datetime(2022,2,7)
yesterday = today - timedelta(days=1)
obj_earth = Horizons(id='399', location='500@0', epochs={'start':str(yesterday), 'stop':str(today),'step':'1d'})

This produces the following output, matching the web query:

[-1.08939344e+08 -1.10724448e+08] km

(As an aside to help diagnose this, you can do obj_earth.uri which shows the query URL string (urlencoded) in the same format as originally posted. This showed that the original Python code was submitting CENTER=0 not the desired CENTER=500@0)


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .