minor bug: jd + 1/2 day, and time units etc.

[gmbrandt]

in main.py we have:

to_jd = lambda x: Time(x, format='decimalyear').jd + 0.5

when we call htof's fitters. I.e. we add a half day to each of the gaia/hipparcos epochs. This is probably wrong, I think it is a vestigial remnant of an old version of htof.
Anyway, this doesn't matter of course for long period companions that we usually deal with

As I think about it, it might never matter because no one would use hipparcos/gaia accelerations to fit a ~30 day orbital period companion where this will matter. But we should probably fix this at some point.

Anyway: this spawns another very minor bug in that we have all RV data files use JD. This is great because it is well defined.
While for relative astrometry, we use either jyear or decimalyear -- but I don't think that is documented anywhere. And there is a ~half day difference between the two
`In [4]: Time(2020, format='decimalyear').jd
Out[4]: 2458849.5

In [5]: Time(2020, format='jyear').jd
Out[5]: 2458850.0
`
If we use tables with units specified, Issue #10 , then this will go away. The quicker fix though is just to change perhaps the input relative astrometry files to always use JD or something (or specify that these must use astropy time decimalyear or astropy time jyear).

[t-brandt]

Relative astrometry currently accepts either BJD or decimal year units (lines 183-186 of orbit.pyx). I currently assume that any time >3000 means that you are using BJD, and that <3000 means decimal year, but yes, I've been sloppy about this. If you specify BJD in relative astrometry then the problem goes away. In practice, we're not going to be directly imaging a short period faint companion for a long time (I don't think), so I believe that this isn't an issue in practice.

[gmbrandt]

Makes sense! Thanks. Closing this issue.