Spacecraft Event Time explains the importance of remembering just how darn slow light is; it takes minutes, hours, and in a few cases almost a day for light to travel one way between humans and their furthest clocks!

As an example only, Wikipedia's Curiosity (rover) says Landing date: August 6, 2012, 05:17:57 UTC SCET (7, 8) screenshot) because the spacecraft used its onboard clock when reporting its own landing.

Other answers here (looking for them now, I might be remembering this complete answers in the form of a comment) have mentioned that a deep space spacecraft's clock is in some cases updated by the ground from time to time, though I'm not sure if that's necessary. If we know the offset and we're the only viewer of the clock (it's not the Grand Central Terminal clock for example).


  1. Are deep space spacecraft event time clocks reset at regular or even irregular intervals to keep them "up to date" somehow, or are they generally left free-running (i.e. if it's not broke, don't fix it)?
  2. If they are, to what timescale are they linked or reset referenced to? (e.g. UTC versus JD and uniform timescales like TAI, TT, and TDB (also see answers to Is GPS time at least “really close” to TAI (International Atomic Time)?)


Bottom line: accelerometers give down, Sun gives azimuth. On-board ephemerides of Earth, Mars, and the location of the rover on Mars, all of which are kept up-to-date by the operations team, allow the HGA to be slewed to track Earth in the sky. There is one more critical instrument and calibration required: the current time.


1 Answer 1


From my experience:

  1. Ground operators work with UTC. All events are time tagged with UTC time stamps. This is a bit of a hassle for programmers who have to deal with leap seconds, but makes everything more organized and understandable for people.

  2. Onboard computers have onboard clocks, which normally count ticks (or seconds) since last reset. The offset between this clock and some epoch time in an absolute time scale is computed and stored somewhere, and might need to be recomputed over time or with resets. In some cases, it is necessary to correct drift from the onboard time scale (which is also noisy) with respect to the absolute time scale.

  3. Nowadays, it is fairly practical to chose GPS time as the absolute scale, but TAI would also work.

  4. Because UTC is used by operators, it might be better to convert an UTC time stamp automatically to either of the scales the onboard computer users (which is either that of the onboard clock or the chosen absolute time scale). Conversion to UTC onboard might also be a hassle due to leap seconds. The automatic conversion could be done on ground or onboard the spacecraft.

  5. JD would also be a hassle because a lookup table would be needed to convert two Julian dates to an elapsed time in SI seconds. But, it is nonetheless used onboard if needed to compute earth/sun/moon accurate ephemeris.

  6. My overuse of the word "hassle" is not on purpose, but does express my discontent with these time handling quandaries.

  7. Onboard clocks are normally only reset if the whole computer is reset, which depends a lot on the operator and software design, it should not be needed as routine. But the offset parameter may be updated rather often.

  • $\begingroup$ Isn't point two basically how Linux handles wall time? Grab the motherboard RTC on boot and add the time since boot to that for wall clock later on? That's simplified of course. $\endgroup$
    – jaskij
    Mar 2, 2020 at 19:43
  • $\begingroup$ @JanDorniak : I don't know enough about linux to answer your comment. But I think it may also depend on which linux distro you chose. $\endgroup$
    – Mefitico
    Mar 2, 2020 at 20:04
  • $\begingroup$ @Mefitico excellent, I always appreciate your answers, thanks! And since you mentioned the hassle of discontinuous time; How do launches avoid leap seconds? Why? $\endgroup$
    – uhoh
    Mar 2, 2020 at 21:44
  • 1
    $\begingroup$ @uhoh : There are pretty good answers in the question you've mentioned. I know people who work in launch sites, and maybe I'll ask them about it. But notice that Kourou only makes around 12 launches per year, normally during the day so avoiding a leap second window is easy (just don't pick the wrong card in a deck of 182, so actually it is hard to bump into it). And in all honesty, I'd totally vote on favor of never launching on leap second addition day. $\endgroup$
    – Mefitico
    Mar 2, 2020 at 22:08
  • 1
    $\begingroup$ @honeste_vivere : For "mission data", such as payload measurements, to each their timing requirement, and thus for each the chosen time base, no obligation to use UTC there in general. As you've noted, I'm mostly talking about housekeeping and ground controller commands. $\endgroup$
    – Mefitico
    Feb 25, 2021 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.