Time is a very deceptive topic for programmers. "I know how time works", they all think. "After all, I use a calendar and clock every day!" Unfortunately, human civilizations have been measuring time for a long time[citation needed], and even our modern systems carry centuries of historical baggage. This article will attempt to give you a broad working knowledge of time, and how it pertains to the computer systems you will work on in your lifetime.

There are two major (and largely separate) concerns related to time: when things happen (instants in time), and how long things take (durations). We will cover each of them in turn.

No matter how confused you may become as you read this article, never forget that time always moves forward at the same rate everywhere. Nothing you do (switching timezones, changing clocks, etc.) can change this fact, and any confusion is simply the result of human notations for time. Unless you have to deal with relativity—in that case, god help you.

When things happen: instants in time

The first major aspect of time for a programmer is the study of when things happen. This is the realm of calendars and clocks.

A first important distinction is the difference between dates and times.

  • A date represents a particular day on a calendar. For example: May 21, 2022. The calendar you are primarily familiar with is the Gregorian calendar, although other calendar systems exist and see some limited use, particularly for holidays and religious reasons.
  • A time on its own represents a time of day—hours, minutes, seconds, and perhaps more depending on precision. For example: 7:45:00 PM.

The combination of the two is often called a datetime or timestamp. Together, they describe a specific moment in time. However, there is one remaining source of ambiguity: time zones.

Time zones

You are already casually familiar with time zones. They reflect the very real fact that different locations on Earth experience the start and end of a day at different times. They are, however, a major source of consternation for programmers, because they involve human ambiguity and politics.

From a programmer's perspective, a time zone can be thought of as a bundle of the following:

  • A time offset from UTC
  • Rules for how this offset changes over time

The former is relatively easy to handle; the latter is fraught with politics and annoying edge cases, and will be discussed in the next section.

The time offset removes ambiguity by anchoring the time to UTC (Coordinated Universal Time), an international standard time that is continuous and not affected by regional policy. A timestamp or datetime is thus a combination of date, time, and time zone or time offset. These three ingredients represent a fully-qualified, unambiguous instant in time.

Be warned that a time zone's offset may not always be a multiple of one hour. There are several time zones that are offset by 30 or 45 minutes from the typical one-hour interval, and historical timezones that predate modern timekeeping may be offset by any arbitrary amount.

UTC and the International Date Line

Broadly speaking, UTC (Coordinated Universal Time) is the date and time at the prime meridian (zero degrees longitude), and is not subject to daylight savings or other discontinuities.

You may have also heard of GMT (Greenwich Mean Time). GMT is also centered at the prime meridian, but has a long history and is no longer used as a time standard. UTC is the internationally standard successor, and the one appropriate for computer use.

The existence of the prime meridian necessitates a date cutoff point at roughly 180 degrees longitude. This is the International Date Line, the point at which you cross from UTC-12 to UTC+12 or vice versa, changing the date as necessary.

Source: The World Factbook (CIA), modified for emphasis. (vector version)

You might think that the International Date Line ensures that no two locations on earth have a time difference greater than 24 hours. But naturally, there are in fact time zones whose time offset is greater than 12 hours from UTC. Rules are made to be broken.

We recommend reading this FAQ by the US National Institute of Standards and Technology. It will reinforce some of these important basics, such as how UTC is defined, and the difference between UTC and GMT.

Check your knowledge:

  • What is the difference between a time offset and a time zone?
  • What is the difference between UTC and GMT?

Daylight saving time and locations

Many locations on Earth observe regular changes to their timekeeping, shifting their clocks forward or backward by one hour to put sunrise and sunset in a different place relative to their working day. Many people think this is stupid, but we programmers are stuck with it until every government on Earth decides to abolish this practice.

The most important implication of daylight saving time is that you must not assume that a day is 24 hours long. A calendar day may be 23 or 25 hours long, depending on the direction of the transition. The visible impact of this is that the day will either repeat or skip an hour, and this change may occur at different times of day depending on the location.

For example, time in Chicago on March 14, 2021 proceeded directly from 1:59:59 CST (Central Standard Time) to 3:00:00 CDT (Central Daylight Time). Likewise, on November 7, 2021, time proceeded directly from 1:59:59 CDT to 1:00:00 CST. Note that when repeating an hour, the time zone resolves the ambiguity.

To help you deal with daylight saving time, you may have heard mnemonics such as "spring forward, fall back", or the terms "gain an hour" and "lose an hour". These terms are unfortunately confusing and appear at times to be in conflict, so here is a cheat sheet:

Coming from Going to Occurs in Clock adjustment Lived experience Analogous to
Standard DST Spring "Spring forward" "Lose an hour" Traveling east
DST Standard Fall "Fall back" "Gain an hour" Traveling west

A useful gut-check for all this is to remember that the Sun rises in the east and sets in the west. Traveling west would thus mean traveling with the Sun and experiencing more daylight—hence, "gaining an hour", and having to adjust your clock backward to account for the extra time in your day.

There are many conflicting explanations for who originally proposed the practice of daylight saving time, why governments actually chose to adopt this practice, and why it has continued to this day. This article does not attempt to clarify any of this, but the author chooses to believe that all this is Benjamin Franklin's greatest prank of all time.

In our Chicago example, it is important to realize that CST and CDT are different time zones. We sometimes colloquially refer to them together as "central time", but there is no such time zone. Rather, state governments in the midwestern United States observe CDT from March to October and CST from November to February. The time of transition is governed by state and federal laws. Other countries that observe CDT and CST may observe them at different times - Mexico, for example, observes CDT from April to mid-October and CST from mid-October to March. These discrepancies can occur even on very small scales - for example, one county in Indiana did not observe daylight saving time until 2006.

This is why many computer systems ask you for your location rather than your time zone. Ultimately, the time zones you observe are determined by your local government, so what often matters is where you live, not just what time zone you are currently observing.

The Internet Assigned Numbers Authority (IANA) maintains a Time Zone Database, often referred to as tzdb. If you have ever seen names like "America/Chicago" or "Pacific/Honolulu", those names were straight out of this database. The data is freely available in a textual source format which is quite easy to follow. It is also heavily commented, with links and anecdotes about the history of timekeeping worldwide. It is a very pleasant read.

Check your knowledge:

  • What is a "time zone" really?
  • Is "eastern time" a real time zone?
  • How might a user in California experience "Pacific time" differently from a user in Mexico?

Leap days and leap seconds

Unfortunately, one year on the Gregorian calendar does not correspond exactly to one solar year. You're probably already aware of how this is handled; every four years, February has an extra day. (Except for years divisible by 100, except for those which are also divisible by 400.) This is not very hard to handle, and it will be accurate enough for at least the next 1000 years.

Unfortunately, there is a more difficult problem - the Earth's rotation is somewhat irregular. A variety of geological effects can cause the Earth's rotation to speed up or slow down, causing a solar day to step out of sync with our clocks. In order to avoid this drift, leap seconds are occasionally observed, extending or contracting the length of the day by one second. Unlike leap years, there is no set schedule for leap seconds - the Earth's rotation is not predictable enough. Computer systems must periodically download new timekeeping information so they always know of any upcoming leap seconds.

Since the year 1972, 27 leap seconds have been observed. At the time of this writing, a negative leap second (shortening the day) has never been observed; only positive leap seconds have been observed (lengthening the day). However, negative leap seconds are possible in theory, and they may someday be required.

All of this has some consequences for programmers:

  • You should not assume that a year has 365 days (because a leap year may make it 366).
  • You probably should not assume that a minute has 60 seconds (because a leap second may make it 59 or 61).
  • 23:59:60 may be a valid time, depending on the day.

The irregular and unpredictable nature of leap seconds has resulted in varying implementations. One common technique for dealing with leap seconds is essentially to ignore them: it is common for time synchronization servers to "smear" the leap second over a period of time, causing their clients to slowly drift until they match with real UTC again. In this case, clients are completely unaware that a leap second is occurring. More information about leap smearing can be found in this article:

To close out, this article explores the possibility of eliminating leap seconds by redefining a calendar day in UTC.

Date representations, the Unix epoch, and the year 2038 problem

coming soon

How long things take: durations

coming soon

Written by Ben Visness.