How are Spacecraft Event Times (SETs) managed; to what timescales are they linked?

Question

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).

Questions:

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)?)

---

^†Comment

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.

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.