fix(time.Observer.transit_times): Use sidereal day. #154
Conversation
caput/time.py
Outdated
| @@ -566,7 +566,7 @@ def _fixup_interval_and_step(self, t0, t1, step): | |||
| # Get the ends of the search interval | |||
| t0 = ensure_unix(t0) | |||
| if t1 is None: | |||
| t1 = t0 + 24 * 3600.0 | |||
| t1 = t0 + 24 * 3600.0 * SIDEREAL_S | |||
There was a problem hiding this comment.
This probably should be STELLAR_S
There was a problem hiding this comment.
Otherwise, I think you make a fair point!
There was a problem hiding this comment.
back to wikipedia I go...
There was a problem hiding this comment.
Do you agree it should be stellar day in the end?
There was a problem hiding this comment.
I think so. If we've specified RA and Dec in ICRS coordinates we should use that reference to calculate the next transit. I could test it by comparing the predicted time between the next two transits to the stellar/diereal day. Practically, it's only an 8ms difference.
tristpinsm
force-pushed
the
tpm/transit-time-sid
branch
from
8795358
to
f73ea6d
Compare
|
I compared the predicted difference between transit times of CygA ("predicted length of day") by In conclusion I think stellar day makes sense to use here. I'm not sure what is responsible for the oscillations in the predicted times. Maybe nutation? the NRAO website says there is a nutation mode on half a year period, but I don't know the magnitude of that effect. |
Use the stellar second to set the end time to one stellar day later if not specified. Otherwise you get two transit times if t0 is within a few minutes of transit.
tristpinsm
force-pushed
the
tpm/transit-time-sid
branch
from
f73ea6d
to
e512ea5
Compare
Use the sidereal second to set the end time to one sidereal day
later if not specified. Otherwise you get two transit times if
t0 is within a few minutes of transit.
This seemed like unexpected behaviour to me.