Possible bug in Hipparcos calculations regarding decimal years and leap years

[sefffal]

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]

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]

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").

[sblunt]

Hey! Thanks so much for pointing this out (and sorry it's taken me so long to dig into it). I'm digging around for more info, but so far I'll share:

• This website gives a conversion from J1991.25 to JD which matches your third comment suggestion. So that's quite good evidence that at least the J1991.25 epoch should be read in the way you suggest!
• It would make sense to me that the delta_epochs are actually in Julian year rather than decimal year. I'd like to find some piece of documentation that says that to be sure. I'm going to keep googling a bit.

Let me know if you've found any more info!

[sblunt]

Ok, more bits of (confusing) info-- the README of the JavaTool 2021 download looks like this. Unit of epoch is just given as yr-1991.25

8 - 14 F7.4 yr-1991.25 EPOCH Epoch

[sblunt]

Whoops, just realized you said exactly that in your first comment. Sorry for restating the obvious!

[sblunt]

More random info dumping of sources: on page 288 of the 2007 Hipparcos 2 reduction book it mentions "where t is measured in years of 365.25 days, counted from 1991.25." The context is a little different, but that's pretty good evidence for me that this is all defined in Julian years as you suggested! I'm going to make that change in my code and see how much it affects some of our tests.

[sblunt]

Ok, I did a test refitting the Hipparcos 5-param model for beta Pic, and the difference is very small. I'd believe the differences I'm seeing in this plot are just the chains not being 10000% converged. That gives me confidence I implemented the jyr change correctly though, so I'll go ahead and PR this once I propagate to our gaia module too. Thanks again!

[sblunt]

One potentially important clarification we can make, however-- the proper motions as constrained above (and as measured by hipparcos, presumably) are in mas/julian yr, not mas/yr. That gets reasonably significant over time.

[sefffal]

Thanks for looking at this! Since I made the issue, I tracked down a couple more details.
I confirmed that Gaia also uses mas / Julian year and J20XX epochs.
I also reached out to Tim Brandt and he confirmed the HGCA is in units of Julian year.

Ok, I did a test refitting the Hipparcos 5-param model for beta Pic, and the difference is very small. I'd believe the differences I'm seeing in this plot are just the chains not being 10000% converged. That gives me confidence I implemented the jyr change correctly though, so I'll go ahead and PR this once I propagate to our gaia module too. Thanks again!

Very nice! I agree it should have almost no difference for these kind of fits. I do wonder if might have a slight impact for orbits with periods < the Hipparcos measurement time, e.g. a couple years. But I'm not aware of any test cases for this unfortunately.