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.


2 Answers 2


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
    Commented 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
    Commented 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
    Commented 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
    Commented 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
    Commented Feb 25, 2021 at 16:40

I work with one of the Mars orbiter spacecraft. On this particular one, we don't try to control the spacecraft clock, but we do measure it so we can convert to UTC or something like it. We manage the clock as follows:

  • The spacecraft clock counts in a 32-bit count of seconds and a 16-bit count of subseconds (65536 subseconds in 1 second). All spacecraft events run on this spacecraft clock, and all spacecraft commands reference this clock only. The spacecraft neither knows nor cares about UTC or any other time scale. The clock is driven by an on-board ultra-stable oscillator, which to my understanding is a precise (and expensive) quartz crystal oscillator with various systems such as temperature-control ovens to make it as stable (constant frequency) as possible. Even though the oscillator is "ultra-stable", it isn't perfect and therefore doesn't tick at precisely 1 second per second. When the clock increments by 1 "second", it is as measured by the oscillator, which means it is close to but not precisely one SI second.
  • The spacecraft was powered off during launch and turned on upon separation. When the spacecraft computer booted up, it initially set its clock to zero. However, soon after, the startup script jammed a particular time value. Nominally, this will set the clock to seconds since midnight on 2000-01-01 (the epoch of the JPL Spice time scale) but it doesn't really matter. As it happens, our spacecraft launched a couple of days late, but the startup script was not changed (because the spacecraft was powered down) so the clock was jammed with the "wrong" time by over 100,000 seconds. This doesn't matter, because we take that into account while commanding the spacecraft.
  • Since that initial startup, the spacecraft clock has run free, without reference to GPS or any other radio signals. If the spacecraft computer were to shutdown and restart, that would reset the clock (to the setting it used at launch), but this hasn't happened to the spacecraft since launch.
  • One of the navigation tasks is "time correlation". The ground station sends up a command to send back the current value of the clock on board. There are dozens of factors that make time correlation complicated, including where Mars is relative to Earth, where the spacecraft is relative to Earth, light speed delay, Doppler, general relativity, etc, etc, etc. One of the most important things is how long it takes the spacecraft to receive, decode, interpret, and respond to this command. It's not instant, but it was carefully measured on the ground and is designed to be constant. Time correlation allows us to measure the clock drift, but we don't try to control it and we never reset the clock.
  • The mission operations center (MOC) uses this time correlation to compare the time on the spacecraft to the time on the ground. Since all teams on the spacecraft use the JPL Spice library, the MOC produces a table in the form of a spacecraft clock kernel. This is a table for converting spacecraft times to ephemeris time, which can be thought of as UTC which takes into account relativity etc and is therefore applicable across the whole solar system. Ephemeris time can be converted to UTC on Earth. The table is in the form of a piecewise linear function. For several Ephemeris times, the spacecraft clock readout and tick rate are used to create a linear time offset.

So, if we want to take a picture of Mars at noon UTC, the mission ops team uses the spacecraft clock kernel to convert to a spacecraft clock, say 712345678:01234. They encode that spacecraft clock count into the command script, send that up to the spacecraft, and then when the clock on board reaches the appropriate time, the command is issued and the picture is taken.

Other spacecraft teams may choose to control the clock. They can update the epoch, but they can also sometimes tune the oscillator, say by running it at a different temperature. Or they can say that the spacecraft computer should count 24,000,001 oscilator cycles as 1 second instead of exactly 24 million. These things together are referred to as "clock steering".

  • $\begingroup$ Thanks for your answer, this is great! Just curious though; 1) a 32-bit count of seconds is only 136 years. How was "2000-01-01" "jammed" into a 32 bits, 136 year clock? 2) since the absolute value of the clock doesn't really matter (this is a good point and you've made it clear) why was the decision made to reset it to a seemingly arbitrary starting value vaguely resembling a correct time. Why was it decided that starting from zero wasn't just as good, if not actually better? Thanks! $\endgroup$
    – uhoh
    Commented Dec 12, 2023 at 22:04
  • 1
    $\begingroup$ 1) In Spice, 2000-01-01 is defined to have an ephemeris time of zero seconds, similar to Unix time zero at 1970-01-01. We don't anticipate our mission lasting to the year 2136, so 32 bits is plenty. It actually is probably overkill, but our spacecraft computer has a 32-bit word size so it's still convenient. 2) There isn't a practical reason, just a convention. It is meant to make the spacecraft clock readout "similar" to ephemeris time for "convenience" but we have run into issues where being close but not exact was inconvenient. $\endgroup$
    – kwan3217
    Commented Dec 12, 2023 at 22:15
  • $\begingroup$ Oh, silly me. Yes computer timescales have their associated epochs. My computer (via Python's time module) says that right now it's "year" 53.946... i.sstatic.net/wpOK6.png and the spacecraft's equivalent function (if it had one) would say it's year 23.9... J2000 stuff. Got it. :-) $\endgroup$
    – uhoh
    Commented Dec 12, 2023 at 22:32

Your Answer

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

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