23
$\begingroup$

The International Space Station is in a different gravitational field than us on the Earth's surface. Almost all computers / protocols depend on the Unix epoch being consistent everywhere. The Unix epoch is same for all computers on the Earth's surface, since they are in the same gravitational field. Do the computers on ISS need to be corrected for the difference in gravitation field and epoch changed likewise.

$\endgroup$
15
  • 11
    $\begingroup$ Even more important, what happens when we run out of seconds in a 32 bit interger in 2038? $\endgroup$
    – geoffc
    Oct 7, 2020 at 20:18
  • 33
    $\begingroup$ @geoffc On the bright side, I'll be retired from software development in 2038. On the dystopian side, I'll probably be dependent on a lot of medical technology relying on 32-bit embedded systems. $\endgroup$ Oct 7, 2020 at 21:53
  • 13
    $\begingroup$ The relativistic effects on timing on the ISS are extremely small, a drift of about 25 microseconds per day, or about 0.3 parts per billion. The clock drift rate on a typical laptop is on the order of 10 to 20 parts per million. $\endgroup$ Oct 8, 2020 at 3:13
  • 16
    $\begingroup$ "Almost all computers / protocols depend on the unix epoch being consistent everywhere." No they don't. $\endgroup$
    – user20636
    Oct 8, 2020 at 8:15
  • 6
    $\begingroup$ You have a bit of a nomenclature issue. The Unix epoch is a fixed point in time, 1/1/1970 00:00:00 UTC. What you probably mean is "Unix time", which is (roughly) the number of seconds since the epoch. However Unix time is a poor approximation for actual time, as for instance it does not account for leap seconds: each day is defined as having 86400 seconds, not one more, not one less, so when leap seconds occur Unix time needs to be adjusted accordingly. See the discussion at en.wikipedia.org/wiki/Unix_time and the comparison between Unix time, UTC and TAI in various cases. $\endgroup$
    – jcaron
    Oct 8, 2020 at 12:45

7 Answers 7

41
$\begingroup$

POSIX time doesn't include leap seconds, and is not implemented the same way in every UNIX, so it routinely gets inconsistent for several seconds every couple of years. It is not a high-precision time scale, and there is little point correcting it for relativistic effects which are smaller than it can represent. GPS has to be corrected --- in particular, the clocks have to run slow on the ground, so that they speed up to the correct rate once in orbit --- but GPS clock errors are measured in nanoseconds, and GPS satellites orbit much farther away than the ISS. Time-based network protocols have to be much more forgiving of errors, or their false alarm rate will be too high.

$\endgroup$
2
  • 4
    $\begingroup$ POSIX time might not, but Unix time can. There is a difference between the POSIX standard and the actual possible behaviours of Unix systems, which can include properly ticking leap seconds. If you want to make the argument that Unix time is sloppy enough that general relativistic effects are the least of one's worries, then leap second support is the wrong hook to hang it from. By far the better arguments are the ones in other answers here, namely that the net effects are small and PC hardwares aren't that accurate anyway. unix.stackexchange.com/a/294715/5132 $\endgroup$
    – JdeBP
    Oct 8, 2020 at 12:10
  • $\begingroup$ "GPS satellites orbit much farther away than the ISS" is not really an argument - note that relativistic effects are almost the same absolute magnitude in both orbits, but have opposite signs! $\endgroup$
    – asdfex
    May 30, 2021 at 13:07
32
$\begingroup$

No.

Computer clocks are inaccurate. They rely on constant corrections to maintain the correct time. Since their inaccuracy is much bigger than the time speed difference between earth and the ISS, it really doesn't matter.

$\endgroup$
12
  • 1
    $\begingroup$ How true -- I once owned a low-end tablet whose clock time would drift by several seconds a day if not connected to the internet (to get a re-sync from some master timing source) $\endgroup$ Oct 8, 2020 at 13:09
  • 2
    $\begingroup$ @user2705196 phone clocks can get their time from base stations (which use atomic clocks, hence the ubiquity of the FE-5680A in surplus) or the internet, so there's no need for them to have any kind of long-term stability, and the manufacturer will take any savings they can get $\endgroup$
    – llama
    Oct 8, 2020 at 17:11
  • 3
    $\begingroup$ @CarlWitthoft Just to make sure it's clear: your CPU clock (the one that drives each tick, and gives the Mhz rating), is completely independent of the one that gives time. $\endgroup$
    – Antzi
    Oct 9, 2020 at 5:20
  • 2
    $\begingroup$ @Antzi: pointless nitpick / fun fact: Yes, Linux for example updates the current system time in a timer interrupt, but for high precision timestamps (like clock_gettime or gettimeofday), on x86 it interpolates an offset to that using rdtsc with a scale factor (and code) exported by the kernel into user-space processes in the VDSO pages. The constant TSC reference frequency is separate from the core clock frequency (making it useful for wall-clock time even when the CPU is turboing up/down), but is derived from the same clock signal, so it actually does come into play as a timesource. $\endgroup$ Oct 9, 2020 at 10:23
  • 2
    $\begingroup$ @Quantic: Have you single-stepped the asm for a call to it? I have. Yes it's imprecise, that's why it's only used for an offset with nanosecond precision relative to the timestamp recorded by the last timer interrupt, like I said. That accurate timestamp is updated every HZ, e.g. 10 ms, in a timer interrupt, so yes the TSC is only used for that small interval. This SO answer also mentions some of those details, and links to the source. $\endgroup$ Oct 10, 2020 at 0:05
28
$\begingroup$

It doesn’t yet matter for most practical purposes. The slowdown from faster motion and speedup from a weaker gravitational field partly cancel out, and the net effect is that time on the ISS is only 0.0000000014% slower than time on Earth, so in its whole 22-year history it has lost about one hundredth of a second.

$\endgroup$
8
$\begingroup$

Computers on the ISS do not rely on UNIX/POSIX time, they rely on GPS time.

Broadcast time is the time broadcast from ISS computers that is intended to be indicative of current time.
The broadcast time message is with respect to the GPS time scale, not the Universal Time Coordinated (UTC) time scale.

The time is accurate to ±1 s:

Due to various reasons, the C&C [command and control] computer clocks are allowed to drift with respect to the Spacecraft Integrated GPS/Inertial Navigation System (INS) (SIGI) time by up to ±1 second. All other ISS computers sync to the C&C computer.

...but can be corrected to ±55 ms:

The GN&C [guidance, navigation, and control] computer calculates the time error of the C&C computer as compared to the SIGI GPS time and provides that time error in Broadcast Ancillary Data (BAD) data. The time stamp of each data packet can be adjusted by adding the time error to create a time stamp that is accurate to within ±55 microseconds.

This is according to the External Payloads Proposer's Guide to the International Space Station (SSP 51071).

$\endgroup$
1
  • $\begingroup$ Does this apply to the Linux PCS and SSC laptops? "Computers on the ISS" is a rather broad category. $\endgroup$ Oct 10, 2020 at 2:41
3
$\begingroup$

Unix time is (sloppily) based on UTC, which in turn is based on TAI (international atomic time). TAI is a coordinate time, an implementation of TT (terrestrial time) defined to be equal to proper SI time of a stationary clock at Earth sea level, and extended to be synchronous everywhere in Earth-centered coordinates.

Even clocks on the Earth's surface must be corrected for altitude to match TAI. Clocks on GPS satellites require a much larger correction. GPS time is kept synchronous with TAI as accurately as possible.

For precise timekeeping on the ISS, we use GPS time, so precise ISS clocks do not tick at exactly one second per proper SI second. For example, the NICER pulsar instrument uses a sloppy (100 ppm) clock in each measurement unit, but calibrates the clock against GPS once per second, thus achieving accuracy of a few nanoseconds relative to TAI after processing.

$\endgroup$
2
  • $\begingroup$ Does this apply to the Linux PCS and SSC laptops? $\endgroup$ Oct 10, 2020 at 14:53
  • 2
    $\begingroup$ @OrganicMarble Without some sort of external time sync, the clocks in PCs and laptops drift rapidly away from both proper time and TAI. As far as I know, the situation on the ISS is the same as any office where there's a mix of computers for configured in different eras for different purposes running different software. $\endgroup$
    – John Doty
    Oct 10, 2020 at 15:18
0
$\begingroup$

Just to have an idea of the order of magnitude:

"Time dilation explains why two working clocks will report different times after different accelerations. For example, time goes slower at the ISS, lagging approximately 0.01 seconds for every 12 Earth months passed."

says https://en.wikipedia.org/wiki/Time_dilation

Similarly, between Earth surface (1 g) and Mars surface (1/3 g), so time goes faster on Mars by things are faster on Mars than on Earth by 555 seconds per 1e12 seconds on Earth (1e12 seconds on Earth is more than 31688 Earth Years!). So you will be celebrating Earth New Year a tad earlier on Earth than on Mars, but Martians won't care, they'll celebrate Mars New Year!

Time dilation between Mars and Earth due to different mass

$\endgroup$
-1
$\begingroup$

The gravitational field doesn’t matter for practical purposes- computers’ performance isn’t measurably affected by gravity. What might be measurable is that the ISS is travelling faster (certainly in terms of ground speed) than terrestrial computers. However, the Earth isn’t stationary but is orbiting the sun, galaxy etc and so (a) the difference may be very small, and (b) if you use the ISS as your frame of reference then it’s stationary and the Earth is moving. Either way, having CD a few seconds of drift either way isn’t generally a problem for communications.

$\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.