22
$\begingroup$

A short comment in the BBC Crowd Science audio program Does Time really Exist?'s discussion of the slow divergence between UTC and TAI (IAT) (coordinated time and international atomic time) says that NASA and ESA for example avoid launches around leap seconds.

Is this true? Is it done out of an abundance of caution, or even an overabundance, or are there mixed clocks, some running UTC and some running IAT and offsets hard-coded in for each launch? Currently the difference is 37 seconds and there have been 27 leap seconds since 1970.

In the past it would not have been much of a burden to avoid them if a launch is considered a few minute or few hour event, but the duration of a mission is often years or decades, so an entire mission can almost never completely avoid a leap second.

So how do launches avoid leap seconds? And why?

Improve this question
$\endgroup$
7
  • 3
    $\begingroup$ My mind is boggled. Space flight normally uses TAI which doesn't have leap seconds. $\endgroup$
    – Joshua
    Commented Jul 9, 2017 at 15:05
  • 12
    $\begingroup$ Because however well you think you've debugged your system, particularly with one-off conditions like leap seconds, things do eventually break (example). If it's some website then it's ultimately not a huge deal, but if there's a nontrivial amount of explosive fuel on the line, then how willing are you to have some random bug actually set things on fire? $\endgroup$
    – E.P.
    Commented Jul 9, 2017 at 18:09
  • $\begingroup$ @Joshua -- If only that was the case. Sadly, it's not. $\endgroup$
    – David Hammen
    Commented Jul 9, 2017 at 23:05
  • 1
    $\begingroup$ New Horizons is going to reach its extended mission target on Jan 1st 2019.. I wonder if the difference in times will affect that mission too. $\endgroup$
    – Cody
    Commented Jul 10, 2017 at 16:19
  • 3
    $\begingroup$ This is a late comment that pertains to the parenthetical (IAT). The acronym is TAI, period. It is TAI (not IAT) in English speaking countries. It is even TAI in Russia, China, and other countries that do not normally use latin characters. $\endgroup$
    – David Hammen
    Commented Dec 24, 2021 at 12:33

4 Answers 4

Reset to default
18
$\begingroup$

Avoiding leap seconds is easy, don't launch at June 30th or December 31st when a leap second is announced, see https://en.wikipedia.org/wiki/Leap_second

It is difficult to test if leap seconds during a launch may cause problems: leap seconds occur only once or rarely twice a year, but there have been a lot of years without leap seconds.

In this century, leap seconds were inserted only in 2005, 2008, 2012, 2015 and 2016. Only 2012 and 2015 there were leap seconds in June. Since the introduction of leap seconds, only the points of time in June and December have been used.

There were no leap seconds in the years 2017, 2018, 2019, 2020 and none announced for 2021.

Improve this answer
$\endgroup$
8
  • 1
    $\begingroup$ Maybe "straightforward" is a better word than "easy". Scheduling $10 to 100 million events is a complicated process involving all kinds of expensive tradeoffs, launch windows themselves can be demanding as well. Are you sure it was always easy in each and every one of the last 27 times it's occurred? $\endgroup$
    – uhoh
    Commented Jul 9, 2017 at 8:11
  • 4
    $\begingroup$ I think launches starting in one year and finishing in the next year are avoided anyway. This way most leap seconds of the past were avoided anyway. Is there an example of a launch started in the last days of december? $\endgroup$
    – Uwe
    Commented Jul 9, 2017 at 8:25
  • $\begingroup$ That's a really interesting idea! It would be great to find out if certain recurring dates are always avoided. Perhaps a SatCat search is possible. $\endgroup$
    – uhoh
    Commented Jul 9, 2017 at 8:29
  • 12
    $\begingroup$ @PearsonArtPhoto: Time is actually really hard to test. You have to make sure that every timepiece which might possibly affect the outcome is synchronized to the fictitious time you are using, or you have to conduct the test during a leap second. Then you have to test every possible permutation of clock drift on one timepiece but not on another. $\endgroup$
    – Kevin
    Commented Jul 9, 2017 at 16:49
  • 5
    $\begingroup$ ... and even if you do conduct your test during a real leap second, there's always the risk that somewhere in the system there's a presumed "non-critical" box that's getting time from public NTP servers ... and everything works fine in the test but on the actual day the NTP server it has slaved itself to fails to declare a leap second. Or the public NTP server may falsely declare a leap second that won't actually occur (I've seen this happen in the wild with otherwise truechiming NTP Pool servers on at least one June 30). $\endgroup$
    – hmakholm left over Monica
    Commented Jul 9, 2017 at 23:18
21
$\begingroup$

It's not just launches. It's, well, everything. It drives me nuts!

Spacecraft flight software almost always have the capability to execute uplinked commands based on time. But what time scale? The operational control systems for spacecraft almost always have the ability to issue timed commands to spacecraft. But what time scale? The various mission planning and analysis systems also are time dependent. But yet again, what time scale?

Some systems support TAI as well as UTC. Others support GPS time as well as UTC. Yet others only support GMT (Greenwich Mean Time), which hasn't existed since 1973. A tiny few support relativistically-correct time scales as well as UTC. The ubiquitous answer is UTC (or GMT in the case of legacy systems from some previous millennium). So, rather sadly, this is the one time scale that is almost always used.

This sadly means that spacecraft should not be doing anything critical near a leap second boundary.

Improve this answer
$\endgroup$
13
  • $\begingroup$ Space is hard, this sounds like it makes it unnecessarily harder though. I'm wondering if GPS time is generally at least very close to TAI even if uncoupled? Is a separate question better? Wait, it is... voila! la question du TAI. $\endgroup$
    – uhoh
    Commented Jul 9, 2017 at 9:58
  • $\begingroup$ @uhoh - GPS time is separated from TAI by a constant offset. $\endgroup$
    – David Hammen
    Commented Jul 9, 2017 at 11:29
  • 1
    $\begingroup$ @David Hammen the offset between GPS and TAI time changes with every leap second. But most time of the year it is constant indeed. $\endgroup$
    – Uwe
    Commented Jul 9, 2017 at 11:42
  • 5
    $\begingroup$ "GMT (Greenwich Mean Time), which hasn't existed since 1973" Note that, confusingly, the local timescale used in the UK is still referred to as "GMT" even though it's really UTC. So, GMT does still "exist", just not in its original form ;) $\endgroup$
    – Lightness Races in Orbit
    Commented Jul 9, 2017 at 13:17
  • 1
    $\begingroup$ @Uwe: For any reasonable spacecraft less than the clock drift of your oscillator. On the other hand, the difference between the gravity well adjustments is within the threshold of measurement. $\endgroup$
    – Joshua
    Commented Jul 10, 2017 at 3:23
6
$\begingroup$

Most satellites I'm familiar with work in GPS time internally, but correct for the time by some kind of a constant that is periodically updated for leap seconds to UTC.

For the specific instance of a launch, it would almost certainly be either a mission clock, or GPS time, that is used internally. Most rockets have some kind of a GPS clock on them, which will enable them to find their position, and keep extremely precise time measurements.

For systems that might require launching at any time (And those do exist), they will specifically check for both positive and negative leap seconds to see how the system reacts to them. But generally internally they use either time since launch or GPS time to keep track, and not UTC time.

Improve this answer
$\endgroup$
7
  • 4
    $\begingroup$ GPS actually includes an offset in it's field, so if you have a GPS, you can update your time via that. Also, you assume that time is critical, it isn't for a lot of satellites. But in general, yes, that is something that should be done. And yes, it can be a bit of a headache, but if it's difficult, someone will figure out a way to automate it. $\endgroup$
    – PearsonArtPhoto ♦
    Commented Jul 9, 2017 at 11:50
  • 2
    $\begingroup$ @uhoh: Basically, yeah. It's done in a pretty robust manner but any technology relying on GPS as a primary reference (and that's not just spacecraft: that's your banking/trading industry, your telecom infrastructure, your analogue and digital radio/television transmission industry... basically anything relying on sync) needs to be aware of leap seconds. And they are. You just don't want to risk it going wrong at a critical time when it's easily avoided. Ideally you wouldn't use an affected timebase at all, but reality dictates that humans want to read timestamps in UTC at some point. & bugs. $\endgroup$
    – Lightness Races in Orbit
    Commented Jul 9, 2017 at 13:22
  • 1
    $\begingroup$ @LightnessRacesinOrbit leap seconds suddenly seem evil, right up there with Chronovores; from The Time Monster. $\endgroup$
    – uhoh
    Commented Jul 9, 2017 at 13:26
  • 1
    $\begingroup$ @uhoh: It's true $\endgroup$
    – Lightness Races in Orbit
    Commented Jul 9, 2017 at 13:44
  • 5
    $\begingroup$ @uhoh: And for the management system side of things (granted this would not be used in safety-critical work) it doesn't help that some OSes don't actually support leap seconds; there is no 23:59:60 on Linux, ever. Its NTP client (assuming one is running) just slews the clock extra slowly for a minute or so. How do you like them apples? :) Timing is hard enough, but time is a real pain in the arse. $\endgroup$
    – Lightness Races in Orbit
    Commented Jul 9, 2017 at 13:45
2
$\begingroup$

I suspect that one of the reasons is for the reference frame synchronization. In fact, if doing statistical orbital determination, even a one error second could throw off your state estimation by a significant amount for a short period of time.

Any deviation larger than a few seconds will have significant effects on simulations too. For example, I am currently working on a project where switching to the True of Date frame from the J2000 corrected significant orbital drift errors when all other variables of the high fidelity simulation were kept identical.

Improve this answer
$\endgroup$

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.