22

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?

uhoh
  • 148,791
  • 53
  • 476
  • 1,473

4 Answers4

21

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.

David Hammen
  • 74,662
  • 5
  • 185
  • 283
  • 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. – uhoh Jul 09 '17 at 09:58
  • @uhoh - GPS time is separated from TAI by a constant offset. – David Hammen Jul 09 '17 at 11:29
  • 1
    @David Hammen the offset between GPS and TAI time changes with every leap second. But most time of the year it is constant indeed. – Uwe Jul 09 '17 at 11:42
  • @Uwe and DH let's keep discussion of that question with the question or answer there, not here! – uhoh Jul 09 '17 at 11:43
  • @Uwe and uhoh: Better said, GPS time is separated from TAI by an offset that varies very slightly with time. – David Hammen Jul 09 '17 at 12:19
  • 5
    "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 ;) – Lightness Races in Orbit Jul 09 '17 at 13:17
  • Even a timescale for a spacecraft based on seconds since launch countdown zero may cause problems if there was a countdown delay. A conversion of this timescale to GPS, TAI or UTC might be necessary. If the spacecraft moves fast for years, what about relativistic effects on spacecraft's clock? – Uwe Jul 09 '17 at 14:24
  • 1
    @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. – Joshua Jul 10 '17 at 03:23
  • It's very hard to find out about the Royal Observatory's continuing role in UTC calibration, because there was a school called "Royal Greenwich UTC" :( – OrangeDog Jul 10 '17 at 15:30
  • As far as I can tell, GMT hasn't "existed" since 1935, when it was renamed Universal Time (now UT1). I believe UTC is still based on mean observations at Greenwich, with leapseconds to keep it near TAI. – OrangeDog Jul 10 '17 at 15:33
  • @Joshua In a GPS satellite, the clock drift of the atomic clocks is smaller than the relativistic effects. There is a correction of the relativistic effects used to avoid a drift of the stimated position. The precision of the atomic clocks is two to three orders of magnitude better than the the relativistic effects. – Uwe Jul 10 '17 at 21:21
  • @Uwe: At least in the first GPS satellites, the atomic clock is on the ground. The GPS satellites are bent pipes. – Joshua Jul 10 '17 at 23:17
  • @Joshua -- That is not the case. Every GPS satellite carries an atomic clock, multiple atomic clocks with more recent GPS satellites. While mass limits means these aren't as accurate as ground-based atomic clocks, they are nonetheless highly accurate. – David Hammen Jul 11 '17 at 01:30
18

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.

Uwe
  • 48,975
  • 4
  • 121
  • 206
  • 1
    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? – uhoh Jul 09 '17 at 08:11
  • 4
    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? – Uwe Jul 09 '17 at 08:25
  • 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. – uhoh Jul 09 '17 at 08:29
  • Testing is easy, basically it's a specific scenario that you test for on the ground. Anything important could be tested for on the ground, what one looks for is some kind of instability that happens after the time switch, which can easily be tested with a Hardware-In-The-Loop simulation. – PearsonArtPhoto Jul 09 '17 at 11:43
  • You too? ;) Maybe "straightforward" is a better word than "easy"! – uhoh Jul 09 '17 at 12:36
  • 12
    @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. – Kevin Jul 09 '17 at 16:49
  • 5
    ... 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). – hmakholm left over Monica Jul 09 '17 at 23:18
  • and even on those days, just avoid launching at or around midnight :) – jwenting Mar 12 '20 at 05:10
6

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.

PearsonArtPhoto
  • 121,132
  • 22
  • 347
  • 614
  • So every time the International Earth Rotation Service, otherwise know as "the leap second people" decide on a new leap second, hundreds if not thousands of satellites have to be notified? Then all of these updates have to be confirmed to make sure the satellite acknowledges the most recent leap-second update? – uhoh Jul 09 '17 at 11:48
  • 4
    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. – PearsonArtPhoto Jul 09 '17 at 11:50
  • @PearsonArtPhoto - It's worse than that. cFE/CFS, mostly from Goddard Space Flight Center, lets spacecraft operators specify stored absolute commands in either TAI or UTC, hardcoded, with the default being UTC (GPS time is not an option). GMAT, also from the Goddard Space Flight Center, apparently knows about UTC and TAI, but not GPS time. Cosmos, from Ball Aerospace, knows about UTC. SPICE, from JPL, knows about UTC and TT, but not GPS time or TAI time. Notice the least common denominator. – David Hammen Jul 09 '17 at 13:19
  • 2
    @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. – Lightness Races in Orbit Jul 09 '17 at 13:22
  • 1
    @LightnessRacesinOrbit leap seconds suddenly seem evil, right up there with Chronovores; from The Time Monster. – uhoh Jul 09 '17 at 13:26
  • 1
    @uhoh: It's true – Lightness Races in Orbit Jul 09 '17 at 13:44
  • 5
    @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. – Lightness Races in Orbit Jul 09 '17 at 13:45
2

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.

ChrisR
  • 6,220
  • 19
  • 43