It’s an early morning for many of us after “springing forward” and losing an hour of sleep over the weekend. While the time change might have a jarring impact on our alertness, our computers are probably humming along without ever noticing the switch. Or did they? It depends on which time system you’re using since computers have many ways to track time. Here are a few of the most common:
Contents
Local Time
The time system that people are most familiar with is that displayed on your watch (or smartphone): local time. There are many complexities associated with local time, and most of them have to do with geography and politics. As you travel around, local time changes. Similarly, local time for a single geographic location can be impacted by Daylight Saving Time (DST), an adjustment applied on different days in different locations or, in some cases, not at all. Furthermore, the DST adjustment date can be changed — by the government, as happened most recently in the United States in 2007. If I’m programming based on local time, I have to keep all of these factors in mind, along with the chance that rules for a given region could change any time the legislature meets, requiring a software update. For these reasons, local time is a poor way to track time internally to your product, although you’ll normally need to convert into local time for display to the user.
UTC Time
One way around this complexity of local time is to use UTC time. UTC is the time at 0° longitude and it does not vary with Daylight Savings. The conversion between local time and UTC is a simple addition or subtraction operation as long as the offset is known. In Colorado, where Cardinal Peak is located, we use Mountain Standard Time (MST) in the winter, which is UTC-07:00, and now, after our spring forward, we’re using Mountain Daylight Time (MDT), or UTC-06:00.
Here’s an example of how these times are related. Since each time base has different units, the plot is not to scale, but it gives an idea of how values move with respect to one another. In this example, the machine was rebooted just after 1:39 am, and Daylight Saving Time is applied at 2:00 am.
Although UTC is not impacted by Daylight Saving, it is adjusted with the addition of leap seconds. For systems with precise timing requirements, the addition of a single second can have unintended consequences, a problem Google famously solved by applying the one-second adjustment as a series of millisecond adjustments throughout the day instead of all at once. They call this technique the “leap smear.” The addition of leap seconds is unpredictable, making it impossible to handle all future adjustments in code.
UTC is also used by the standard distributed time synchronization protocol, NTP. The subject of NTP is another blog post on its own, but simply, there are computers with very precise timing that run NTP servers. Other computers run NTP clients, which periodically receive timing updates from the NTP servers. The NTP client will then adjust the time of the host clock, either by resetting the current time or by gradually adjusting the time in small increments until the difference is corrected. Since NTP servers are corrected for leap seconds, NTP clients receive these adjustments for “free” without needing special code.
Unix Time
When even one-second adjustments are too much uncertainty for a given system, the time base of choice is often Unix time or Epoch time, which does not get adjusted for leap seconds. Unix time is defined as the time since midnight (UTC) on January 1, 1970. This value is commonly represented in seconds or milliseconds, with some applications even tracking the time in microseconds. While Unix time will drift slightly with respect to the sun as leap seconds are ignored, the overall simplicity of this time base makes it a very common choice in a wide variety of software solutions.
System Time
Another time we typically use when playing audio and video on a machine is the system time or “up-time” of the machine. This time system has the property that it is always monotonically increasing, something very important in displaying A/V streams. People generally don’t enjoy the viewing experience when the audio or video jumps backward, even for a split second. The constantly increasing feature of this time base is desirable, but the time values returned only have meaning for that specific machine. In distributed systems, the system time cannot be used for synchronization between machines because each machine will have a different up time without a standard conversion to a common time base. Also, hardware clocks drift ever so slightly; over time, this can cause noticeable disparities between different machines. Both of these limitations mean we typically convert a system timestamp on events and messages to UTC or Unix time before sharing it with other machines — even if the timestamps are stored in system time on the local host.
There are many more options for tracking and displaying time, but this list serves as an overview of some of the most common choices. They all have advantages and disadvantages, which make them uniquely suited for different situations.
Come to think of it, maybe I’ll sleep better if I switch over to UTC or Unix time at my house before the next Daylight Saving adjustment.