Time Standards Reference

Notice how as the years go by we learn more, and so TT(TAI), as well as older BIPM estimates, are seen to be increasingly flawed. The first analysis, TT(BIPM92), showed that TAI had diverged from the epoch. TT(BIPM93), TT(BIPM94), and TT(BIPM95) continued to refine this. At this point, we found that thermal radiation was affecting Caesium clocks. This discovery (and correction, reflected in TT(BIPM96)) showed that TAI had diverged even further than was previously thought. Hence, all previous BIPM predictions were also in error, jumping off the x-axis zero-line. More corrections were—and continue to be—added.

Notice how at each year, the final slope of TT(TAI) is roughly flat. This signifies that all known sources of error up to that time have been controlled for, and TT(TAI) is not diverging further from the contemporary estimate of TT. This is because of the frequency steering, which is used to correct all known sources of error.

^{[1]_{Nowadays, many minuscule corrections compensate for tiny sources of error. E.g. some kinds of clocks are corrected for Earth's magnetic field on dipoles of individual atomic nuclei. An appalling amount of effort goes into making such things right.}
[2]_{Presumably from "Temps Atomique" ("Atomic Time"); "TA" is nearly un-Google-able.}
[3]_{The commonly presented figure is "more than 400". I derive a precise count of 521 atomic clocks from BIPM's timescale data (specifically its 2015 clock rate table—the most recent, as of late 2016).}
[4]_{I haven't ever seen "ÉAL" instead of "EAL", though it would make more sense. Oh well.}
[5]_{Descriptions of the operation of ALGOS are universally vague—at least, I couldn't find a definitive description of it from BIPM; it seems that ALGOS is regarded as semi-secret. It is some species of weighted average, though. Perhaps the minutiae are regarded as unimportant for public dissemination.}
[6]_{These corrections tend to be coarser. E.g. the EAL average is not valid at the geoid; most clocks tick too fast because they are above sea level, and hence gravity is a bit less. The frequency steering fixes this, and has been used to correct errors (we'll see this soon).}
[7]_{That is, TAI cannot be measured in real-time; "current" TAI timestamps are actually extrapolations from Circular T. Despite BIPM's discouraging such usage, there isn't a ready alternative. As far as I can tell, nowadays TAI's extrapolation is assumed to be perfect (e.g. in the definition of UTC, later). Since it actually is to within the tolerance our best instruments, the distinction is more-or-less irrelevant.}
[8]_{You might occasionally see the year 1997 instead. This seems to be due to a typo in the SOFA documentation; if you read the original source linked above, you'll find that 1977 is correct.}
[9]_{Although TAI had been defined as early as June 1970, this epoch also marks the time at which the modern definition I described above was adopted: TAI was slowed by 1 part in a trillion (see pg. 27, resolution 2), tied to EAL, and decreed to be henceforth adjusted by varying the transformation therefrom (i.e. frequency steering).}
[10]_{The weird offset by 32.184s in TCB, TCG, and TT is to provide continuity with an older time standard.}
[11]_{The offset for TDB is usually written instead as "32.184s - 65.5μs". That -65.5μs offset is a more-recent addition (so some sources don't have it). There were terrible problems with TDB, and a complete redefinition was eventually required. While maintaining continuity with the older TDB, it was impossible to both keep the new TDB-TT centered around zero and to synchronize the new TDB without an offset at the epoch. Most models had implicitly picked being centered around zero, and so it was the -65.5μs offset that was chosen for the redefinition. A more complete history can be found here or in Time: From Earth Rotation to Atomic Physics §8.5.6. But again, since continued use of TDB is discouraged; don't worry too much.}
[12]_{The redefinition of TDB implicitly redefines the JD (Julian Date) to be this value. The "0.0003725" corresponds to the "31.184s" offset. We shall not need to discuss JD further either.}
[13]_{See? It's like a function! "TT(TAI)" instead of "f(x)".}
[14]_{Indeed, this is the definition of TT(TAI) from IAU 1991.A4.IV.9 (see pg. 6).}
[15]_{Unfortunately, there's a lot of sloppiness; when people say e.g. "TT" they often mean "TT(TAI)". I won't do that.}
[16]_{As far as I can tell, the "15" is because it describes data up through 2015; it was published in early 2016.}}

Making It Useful I: Calendars

So far, we've only talked about clocks (imaginary and atomic) ticking off seconds. Let's briefly sidetrack and talk about days and dates.

If you didn't know, all dates you've probably used were given in the Gregorian calendar—the modern Western calendar. The Gregorian calendar (introduced 1582^[1]) was developed directly from the Julian calendar (introduced 46 BC)^[2].

The difference is how they handle leap years. In the Julian calendar, there is exactly one leap day every four years falling on the familiar February 29th. So, on average, there are 365.25 days per Julian year. Unfortunately, this is not accurate over more than a century or so. Christianity got annoyed that their holidays were moving around relative to the equinoxes, and so the Gregorian calendar was introduced. The Gregorian calendar removes the Julian calendar's leap days that are divisible by 100 but not 400. For example, 1700, 1800, and 1900 were not leap years, but 1600 and 2000 were. On average, there are 365.2425 days per Gregorian year.

The Gregorian calendar works very well. If you count out days of 86 400 seconds each and follow the calendar, you'll be in almost exactly the right place relative to the Sun for millennia into the past or future.

But . . . not exactly so.

^{[1]_{Unfortunately, because the real-world is a terrible place, the standard was adopted slowly. The gory list of adoption details (when such are known) can be found here.}
[2]_{Extrapolating either calendar before its invention makes it proleptic. So e.g. one can talk about the date 1500-01-01 in the "Proleptic Gregorian Calendar". In practice, it's a fancy word that doesn't mean anything.}}

Making It Useful II: Tying to Astronomical Time Standards

See, the length of a (solar) "day" is not actually a constant. It varies due to tiny changes in the Earth's rotational rate, its orbit around the Sun, and so on. To handle this, there is a family of time standards called UT (Universal Time) that are based on direct or indirect measurements of it. The two important ones are UT1 and UTC^[1].

UT1 is based^[2] on Mean Solar Time at 0° longitude, a measure of the Sun's position in the sky^[3][4]. UT1 is defined by the IERS (International Earth Rotation and Reference Systems Service). Officially, it is given out irregularly in IERS Bulletin D, expressed as DUT1, a difference from UTC defined as DUT1:=UT1-UTC. In practice, more precise values come from IERS Bulletin A via the United States Naval Observatory (see cols. 59 through 68).

Well, what is UTC? UTC (Coordinated Universal Time) reconciles the SI second-ticking awesomeness of TAI with the universe-following relevance of UT1. UTC is now the de-facto world standard of "Civil Time" (time that people actually commonly use). UTC ticks SI seconds, just like TAI, and in modern times ticks at the same instant as TAI. However, UTC is set, by means of occasional leap seconds (announced six months in advance by the IERS in their IERS Bulletin C; as of late 2016, there have been 26 so far), to be within 0.9 seconds of UT1^[5]. So UTC is almost the same time as UT1, but gloriously, it ticks well-defined SI seconds instead.

What is a leap second, you ask? It's basically a 61st second inserted^[6] at the end of the last minute of a particular day. For example, consider the leap second in June 2015 (its announcement). The difference between 2015-06-30 23:59:59 UTC and 2015-07-01 00:00:00 UTC would ordinarily be one second. However, a 61st second was added in-between, written 2015-06-30 23:59:60 UTC. The practical upshot is that the difference was actually two seconds. The effect is that UTC dropped a bit further behind TAI (which doesn't stop for nuthin), to fall more in-line with UT1. Sequentially, it looked like this:

You may also encounter the term ΔT (sometimes written "dT", or "DT"). ΔT is defined as ΔT:=TT-UT, but in practice, values are estimated by ΔT≈TT(TAI)-UT1 (or, equivalently, calculated from DUT1 as ΔT≈[leap secs]+42.184-DUT1). The value of ΔT is of interest because it reflects the changing rotational speed of the Earth. Intuitively, ΔT is the error one accrues from trying to use the TT idealization.

^{[1]_{Be aware that evil people will sometimes say "UT" when they really mean "UT1". Also, many people say "GMT" when they mean "UTC"; UTC replaces GMT, which is no longer scientifically defined.}
[2]_{I say "based" because I don't actually have a precise definition. Finding out anything less superficial about UT1 is astonishingly difficult.}
[3]_{In-practice, since measuring the ever-mercurial Sun is hard, it's measured from quasars, the Moon, and artificial satellites.}
[4]_{Since a solar day varies in length, its 86 400 UT1 seconds also vary in length (they are not SI seconds). As a consequence, you need to convert a UT1 timestamp to something like TAI before doing any arithmetic on it. We won't talk about UT1 seconds again; no one uses them because they make everyone sad.}
[5]_{You might have noticed that UTC tries to be close to UT1, but that the data for UT1 is given as an offset from it. At first glance, this appears circular. It's actually okay because UTC is really tied to TAI, and UT1 is actually measured from the sky.}
[6]_{Or, in theory, skipped, although this has not yet been required.}
[7]_{Precise UT1 data is only available for 2015-07-01 00:00:00 UTC. However, the value for the previous day (-0.6760327) suggests that DUT1 was varying by -600.6μs/day. So these figures are correct to their given measurement tolerance of 6μs or so.}
[8]_{We shall discuss UNIX time soon. It's here so that I don't have to write this table twice.}}

Making It Useful III: Offsets

Most people don't like the complexity of living on a roughly spherical planet, and sortof wish the whole problem would just go away. If you thought the preceding was complex, wait 'til you see the needless complexity average citizens/politicians invented so they wouldn't have to do addition.

The obvious approach is to split the world into "timezones", all of them tied to UTC. You can make a list of 24 timezones, each 15° of longitude and all offset sequentially by one hour each.

Then, because summer has more light, you can add an additional, seasonal shift to make sunrise occur at a more-constant time on the clock (this also has the effect of an extra hour of light in the evening). This approach, as well as the changed time itself, is called Daylight-Saving Time (DST) or "Summer Time"^[1]. Thus, three time standards are generated per UTC offset: the standard time (ignores DST), the daylight-saving time (same, but plus one hour), and the generic zone, which switches between the two as appropriate. For example, the generic zone "Pacific Time" switches between "Pacific Standard Time (PST)" during standard time and "Pacific Daylight Time (PDT)" during DST.

^{[1]_{The common Americanism "Daylight Savings Time" (with an "s") is erroneous. Also, the hyphen is preferred.}}

Making It Useful IV: The Problems

But, there are problems. See, the country Kiribati is made up of several islands, and if you make the aforementioned zones, you'll find that poor Kiribati is cut in half by the International Date Line—with local times differing by a full day! This got to be so confusing that in 1995 two more time zones were added (UTC+13:00 and UTC+14:00). Other countries all did similar things, some with much-less-reasonable motivation. Nepal, for example, added its very own timezone in 1986 (UTC+05:45), since that better fits Kathmandu. On the other hand, China geographically spans five time zones, but officially only has one, corresponding to Beijing.

Nepal and China, like many other countries, also ignore daylight-saving time. To begin with, DST makes international collaboration extremely complex (which is partly because there exists an absurd variety of incompatible implementations of DST, so nothing is synchronized). DST also causes a quantitative spike in both lost productivity and suicides.

Everyone also redrew all the timezone boundaries according to political lines, so they were irregularly shaped and didn't correspond to degrees of longitude anymore anyway. But, funny thing: political boundaries are not eternal. Over time, new countries sprang up while old ones split, merged, or disappeared. In the process, timezones changed meanings, so now the system you use to measure time requires you to know what date it is when you're asking and so you have multiple timezones for the same place. In some cases, different ethnic groups living in the same region wanted different timezones or different observance of DST, so now you have multiple timezones for the same place, at the same time. As if it could possibly get any worse, countries also took a lackadaisical approach to implementing leap seconds, upon which the whole concept of UTC is based in the first place. Some countries couldn't get it together in time (leap seconds being announced "only" six months in advance), while some countries decided just not to bother.

All this is such a catastrophe that three things are now true:

1. It is up to individual people, their computers, and those computers' OSes to specify what timezone they want to be in.
2. All the horrific rules for timezones are centralized and abstracted into an international standard timezone database, which is maintained by IANA (Internet Assigned Numbers Authority). The database also describes (idealized representations of) local implementations of leap seconds.
3. Basically all scientific collaboration that takes place in more than one institution is coordinated using UTC instead.

Computerization I: UNIX Time

UNIX Time (no standard abbreviation, but UXT seems good) is the de-facto method by which all modern computers measure time. Windows, Linux, and OSX all measure time this way. On these platforms, it's what the C library function "time(...)" returns, despite not technically being obligated to. UXT is widely misunderstood, even by UNIX experts. The basic idea is that it's a count of seconds since 1970-01-01 00:00:00 UTC. The confusing part is that it is not a count of SI seconds; it is a count of UNIX seconds.

UNIX seconds were originally defined rather badly, but a working definition has emerged, become consensus, and is being gradually formalized. Now, as implicitly defined by the Single Unix Specification §4.15, UNIX seconds are the same as SI seconds, except for the last second before a leap second is to be inserted^[1]. That last UNIX second is either stretched out to be two SI seconds long (thus covering the leap second), or else is repeated once (with the same effect)^[2]. An example of UXT during a leap second was given in the table above.

I describe UXT as pretending leap seconds had never been inserted into UTC in the first place^[3]. Of course, "UTC doesn't have leap seconds" is as bald-faced as lies come, since literally the whole point of UTC is that it does. Most resources instead say very confusing/misleading things, such as "[UXT is ]the number of seconds since Jan 1st 1970, 00:00 UTC, but without leap seconds" (ref) or not distinguishing SI seconds from UNIX seconds at all (e.g.). As a direct and unfortunate consequence, most programmers erroneously still treat UNIX seconds the same as SI seconds because they don't know any better, and so there is still a godawful mess concerning real-world code.

The problem is exacerbated by poor language support. For example, the C language function "difftime(...)" returns the difference between two UNIX timestamps. Internally, it is implemented as a simple subtraction, which means that the result is given in UNIX seconds, not SI seconds. But since UNIX seconds are intrinsically tied to timestamps (because you need to know whether they include leap seconds), the result is utterly meaningless. It might be SI seconds, but there might have been a leap second in there. You can't know, because differences are relative time, not absolute.

^{[1]_{Note: UNIX seconds, when they tick, tick at the same instant as TAI and UTC do. That is, the offset between either in SI seconds is always an integer.}
[2]_{POSIX requires this latter approach.}
[3]_{This means that a particular UNIX timestamp can correspond to either a particular SI second, or to a pair of consecutive SI seconds (the latter of which was an inserted leap second). If a negative leap second were to occur in the future, there would be a UNIX timestamp that refers to a time that doesn't exist. All this confusing ambiguity as to which SI second is being referred to is the ultimate result of lying to yourself.}}

Computerization II: Handling Leap Seconds

How are leap seconds handled by real-world systems? The short answer is, poorly. Even today, much, if not most^[1], professional software gets it utterly wrong (enough to e.g. cause government agencies to suspend operations and to bring down servers at Google).

Theoretically, UXT defines what should happen. In practice, the UXT self-delusional timekeeping coupled with a legacy of ignorant, wrong code, leads to absurd glitches and policies. For example, the stock exchanges worldwide closed for the 2015-06-30 23:59:60 UTC leap second. Milliseconds of difference are worth literally millions of dollars in the stock exchange. They were (rightly) afraid of bugs in their timekeeping algorithms.

To accommodate bad software, which is completely clueless of the concept of leap seconds, some systems were configured to adjust their clocks' tick rates to smear it out over several seconds. Many timekeeping servers (which the computing device you're using right now probably syncs with regularly) implement this non-scientific, irreproducible policy, and there's prettymuch nothing you can do about it.

^{[1]_{Seriously. "Most".}}

What Should I Do?

When writing code or discussing time, your treatment of time should depend on what you're trying to do. Let's assume you want to be as accurate as possible, not necessarily as compatible as possible.

Summary

We have discussed three idealized, imaginary time scales: TCB, TCG, and TT. These were tied to measurements by atomic clocks (TAI) by means of the 1977 epoch. We can estimate these time scales using TAI—for example, using TT(TAI), which is a linear offset, or better, a continually improving estimate (currently TT(BIPM15)).

It is useful to define a system of time (UT1) and a calendar (Gregorian) that are related to the Earth's rotation and orbit. The Gregorian calendar has leap years every four years, except every century not divisible by 400.

To wed TAI's accurate timekeeping to the useful time values of UT1, the UTC standard was eventually developed. UTC ticks at exactly the same instant and rate as TAI, but to keep it roughly in-sync with UT1, leap seconds are occasionally removed from/inserted into UTC. UTC is the current worldwide standard for time.

Local times are conversions of UTC to a timezone: one of a horribly complicated mess of offsets from UTC, now maintained by IANA.

On computers, time is measured by UNIX Time (which I call UXT). UXT is based on UTC; however, UXT handles UTC's leap seconds by pretending they didn't happen. This has led to hopelessly broken software and complicated workarounds.

Conclusion

I hope you've found this to be illuminating of the issues involved, or perhaps informative, or even useful. Again, your corrections and feedback are always welcome.

COMMENTS