Does Orbiter know what time it is?

[BrianJ]

Hi,
I've been messing around with Celestia recently and discovered that all it's ephemeris files (.ssc and .xyz files) are referenced to TBD (Barycentric Dynamical Time) which is the same as JPL Horizons CT (Coordinate Time).

Whenever you request pos/vel vectors or osculating elements from Horizons, the time you input and the time returned as the ephemeris epoch are CT (Coordinate Time).

CT is not the same as UT or UTC.

UT is always within 0.9sec of UTC, and UTC is kept in line with UT by adding leap seconds to UTC every so often (at midnight June 30 or December 31).

For this purposes of this post, I'm going to ignore the difference between UT and UTC - we know it's going to be less than 1sec.

As far as I can tell from the web CT = UTC + 32.184sec + (leap seconds)
and the current leap second count is 34.

Thus, currently CT = UTC + 66.184sec

Now, Orbiter uses MJD/UT. Starting a scenario with parameter Date MJD55000.5 shows a UT time of 18 June 2009 12:00:00 UT.

So, thinks I, if I want to get vectors(for a spacecraft,say) from Horizons for this scenario time, I should use the correct CT time, which would be UT + 66.184sec = 18 June 2009 12:01:06.184

But this doesn't work in Orbiter - it puts my spacecraft 1000's of km away from where it should be. Whereas requesting the vectors from Horizons using the UT time without the 66.184sec offset works very well.

Conclusion: as far as the positions of Orbiter's Earth,Moon,Planets,etc. are concerned the time shown by the on-screen clock in Orbiter is actually CT not UT, and the MJD date used in the scenarios is referenced to CT not UT.

No big deal, but if you're running a historical simulation and your historical information says "launch occured at 18 June 2009, 12:00:00 UT", in Orbiter you should launch 66.184sec earlier, at 11:58:53.816 UT by the Orbiter clock.

Maybe I'm wrong, I find all these different timescales quite confusing! Check it for yourself if you're interested.

Here's some useful links about time scales:
http://star-www.rl.ac.uk/star/dvi/sun67.htx/node222.html
http://tycho.usno.navy.mil/systime.html
http://ssd.jpl.nasa.gov/?horizons_doc#timesys

Regards,
Brian

 

[Quick_Nick]

I'm not sure if I get what you are trying to say. But if you are saying that the planets aren't where they should be, keep in mind that Orbiter is completely Newtonian and doesn't simulate the time it takes for light to go from one planet to another and doesn't simulate any relativity.

 

[BrianJ]

I'm not sure if I get what you are trying to say. But if you are saying that the planets aren't where they should be, keep in mind that Orbiter is completely Newtonian and doesn't simulate the time it takes for light to go from one planet to another and doesn't simulate any relativity.

No, nothing to do with relativistic effects or light delay time. The need for different timescales for specifying ephemerides arises from the non-uniform rotation period of the Earth.

Essentially I'm saying that if Orbiter uses MJD/UT for it's clock and scenario reference, I should need to use a 66.184sec offset when getting ephemeris from JPL Horizons - but I don't.

 

[tblaxland]

I had reason to contemplate this question recently here: http://www.orbiter-forum.com/showthread.php?p=100197#post100197 so I'll sharee my musing on the matter.

Hi,
I've been messing around with Celestia recently and discovered that all it's ephemeris files (.ssc and .xyz files) are referenced to TBD (Barycentric Dynamical Time) which is the same as JPL Horizons CT (Coordinate Time).

I am not a big Celestia users but I have looked at some of its code in the past and as far as I can tell it uses TDB. JPL uses Teph, which is functionally equivalent to TDB although technically slightly different. These are not coordinate times - for that you want TCB. TDB was deprecated by the IAU in favour of TCB but TDB can still be used by converting between the two (the difference is about 490 ms/yr according to Wikipedia). The two differ in tick rate as observed from Earth: when TDB was invented its tick rate was meant to be the roughly same as TT (or TDT as it was called at the time). The important thing is to use the same time scale as the emphemerides are published under. As far as I can tell, that is TDB for VSOP87 (which Celestia also uses IIRC). The error between TDB and TT is <2 ms.

Conclusion: as far as the positions of Orbiter's Earth,Moon,Planets,etc. are concerned the time shown by the on-screen clock in Orbiter is actually CT not UT, and the MJD date used in the scenarios is referenced to CT not UT.

Based on my comments above, that is correct except that the time is actually TDB not TCB.

No big deal, but if you're running a historical simulation and your historical information says "launch occured at 18 June 2009, 12:00:00 UT", in Orbiter you should launch 66.184sec earlier, at 11:58:53.816 UT by the Orbiter clock.

Correct, just remember that the number of leap seconds will be different depending on when your historical mission is launched.

Here's some useful links about time scales:
http://star-www.rl.ac.uk/star/dvi/sun67.htx/node222.html
http://tycho.usno.navy.mil/systime.html
http://ssd.jpl.nasa.gov/?horizons_doc#timesys

I'll add this one:
http://aa.usno.navy.mil/publications/docs/Circular_179.pdf

 

[Chode]

H

Conclusion: as far as the positions of Orbiter's Earth,Moon,Planets,etc. are concerned the time shown by the on-screen clock in Orbiter is actually CT not UT, and the MJD date used in the scenarios is referenced to CT not UT.

No big deal, but if you're running a historical simulation and your historical information says "launch occured at 18 June 2009, 12:00:00 UT", in Orbiter you should launch 66.184sec earlier, at 11:58:53.816 UT by the Orbiter clock.

These statements are correct. I posted this info on the beta testers forum about a year ago so that martin would be aware of it, in case he might want to fix it.

Regards

 

[BrianJ]

Thanks tblaxland and chode, I was starting to think I was losing the plot over this one!

Well, whatever time it is there, it's always teatime here ;-)

Cheers,
Brian

 

[Andy44]

I thought it was beer-o-clock?

 

[NukeET]

I thought it was beer-o-clock?

Isn't it beer-o-clock somewhere in the world?

 

[Chode]

As far as I can tell from the web CT = UTC + 32.184sec + (leap seconds)
and the current leap second count is 34.

Thus, currently CT = UTC + 66.184sec

No big deal, but if you're running a historical simulation and your historical information says "launch occured at 18 June 2009, 12:00:00 UT", in Orbiter you should launch 66.184sec earlier, at 11:58:53.816 UT by the Orbiter clock.

Thinking about this a bit more, I realized that you should actually launch 66.184 seconds later by the Orbiter clock since Orbiter clock = CT = UTC + 66.184sec

Regards

 

[BrianJ]

Of course, you're right. I got it back-to-front (as usual).

 

[martins]

Thanks for the review. I do remember that this topic did come up a while ago.

So if I understand this correctly, this problem could simply be corrected by replacing the 'UT' designations on the simulation display and documentation with 'CT' or 'TBD' (which of these is more common?) and by making it clear that all date definitions refer to coordinate time.

The only occasion when UT times may be required is if the user selects 'now' as a date designation (e.g. by not providing a date in a scenario, or by clicking 'Now' in the scenario editor). Since the computer's system time refers to UT (plus time zone offset), these values would need to be shifted by 66.184 seconds (providing a potential source for confusion ).

A bit trickier would be the actual display of UT times. For past dates, this requires a lookup table of leap second events. For future dates, it presumably isn't possible anyway.

 

[tblaxland]

So if I understand this correctly, this problem could simply be corrected by replacing the 'UT' designations on the simulation display and documentation with 'CT' or 'TBD' (which of these is more common?) and by making it clear that all date definitions refer to coordinate time.

TDB would be correct but it would not mean a lot to many people. But then again, maybe it will achieve a incrementally greater education of the Orbiter community

A bit trickier would be the actual display of UT times. For past dates, this requires a lookup table of leap second events. For future dates, it presumably isn't possible anyway.

That is what Celestia does. You can see it here at line 62. Not particularly practical for Orbiter because it can't be updated, so you would want a config file to hold the leap second data. For Celestia, the solution is to use a leap second SPICE kernel.

---------- Post added at 18:30 ---------- Previous post was at 15:24 ----------

you would want a config file to hold the leap second data

As an alternative, the leap second data could be automatically retrieved via ftp: ftp://maia.usno.navy.mil/ser7/tai-utc.dat

 

[Chode]

A bit trickier would be the actual display of UT times. For past dates, this requires a lookup table of leap second events. For future dates, it presumably isn't possible anyway.

It's even a bit more complicated than that. Leap seconds have only been in use since 1972, when UTC was "synchronized" with atomic time (TIA) (the second was made to be the same length for both systems). From 1961 to 1972, UTC was corrected (both in offset and rate) on average every few months. So during this time, the length of a UTC second actually changed frequently. Prior to 1961, there was no UTC, only UT, which was also a moving target.

If you want to show accurate UTC (+/- 1 sec), you really only need to cover from 1958 to present (the spaceflight era), and could use a lookup table of leapseconds. Prior to that, UTC has no meaning, and into the future, we cannot predict.

Regards

EDIT: Probably the simplest thing to do would be to just remove the "UT" label in front of the Orbiter time display, and write up a short technote that describes what "Orbiter time" is (TDB, CT for JPL's Horizon) and how to translate to UTC for those who really want to know.