search

sblunt / orbitize

Orbit-fitting for directly imaged objects
https://orbitize.info
Other
74 stars 43 forks source link

Possible bug in Hipparcos calculations regarding decimal years and leap years #372

Open sefffal opened 1 month ago

sefffal commented 1 month ago

Describe the bug I'm working on hipparcos modelling in my own code and ran into this problem. I thought I'd check how orbitize! does it, but I think we might both have the same error.

The hipparcos IAD residual data gives times in units of "1991.25 + year". In the hipparcos file, currently the code does:

times = iad[1] + 1991.25
# later...
epochs = Time(times, format="decimalyear")

The problem is I don't think that the offsets computed as 1991.25 + fractional_year should be considered a decimal year time. This is an issue only for scans between 1992 and 1993, because 1992 is a leap year with an extra day (366 days instead of 365).

cc @semaphoreP

sefffal commented 1 month ago

I think it would be more correct to convert 1991.25 from decimal year to MJD, and then add offsets multiplied by one Julian year (365.25). But I'm not positive.

sefffal commented 1 month ago

One more note: I believe the Hipparcos catalog epoch is actually "J1991.25", which isn't technically a decimal year either:

Time("J1991.25", format="jyear_str").decimalyear

Gives an answer that is 7 hours different than Time(1991.25, format="decimal year").