At 23:59:60 UTC on June 30, 2012, a second was added to the world’s clocks. Within minutes, Reddit, LinkedIn, Mozilla, Gawker, and dozens of other major websites had crashed. Their servers were running at 100% CPU, locked in tight loops that made them completely unresponsive. The culprit wasn’t a cyberattack or a hardware failure—it was the handling of a single extra second.

The Linux kernel’s high-resolution timer subsystem, called hrtimer, had gotten confused by the leap second. When the system clock stepped backward by one second, sleeping processes were awakened prematurely, flooding the CPU with activity. Java-based applications like Cassandra—the database powering Reddit—were particularly affected. The site was offline for over an hour.

Linus Torvalds, Linux’s creator, later commented: “Almost every time we have a leap second, we find something. It’s really annoying, because it’s a classic case of code that is basically never run, and thus not tested by users under their normal conditions.”

This incident illustrates a fundamental truth that every programmer eventually learns: time is not what it appears to be.

The Illusion of Simple Time

Humans have kept time for millennia using the sun. A day was simply the period from one sunrise to the next. But as civilization grew more complex, this became problematic. Every city had its own local time, based on when the sun reached its highest point. In 19th century America, a traveler going from Maine to California would pass through over 300 local time zones.

The railroad industry changed everything. In 1876, Scottish-Canadian engineer Sandford Fleming missed a train in Ireland because of confusion over local time. This frustration led him to propose a system of 24 global time zones, each spanning 15 degrees of longitude. The idea was adopted at the 1884 International Meridian Conference in Washington, D.C., establishing Greenwich, England as the prime meridian and the foundation for global timekeeping.

But what seemed like a neat mathematical solution became increasingly messy in practice. Political boundaries, colonial histories, and arbitrary decisions created a patchwork of exceptions that no simple model could capture.

The Database That Runs the World

Today, virtually every computer on Earth relies on the IANA Time Zone Database—often called the tz database, zoneinfo, or simply “the Olson database” after its original creator, Arthur David Olson. This database, maintained since the 1980s, contains the complete history of time zone rules for every location on Earth.

The database is remarkably comprehensive. It doesn’t just store current offsets—it records every historical change. When Venezuela shifted from UTC-4 to UTC-4:30 in 2007 (a decision by President Hugo Chávez), the database documented it. When Samoa skipped December 30, 2011 entirely to cross the International Date Line, the database captured it. When Turkey decided to stay on permanent summer time in 2016, the database was updated.

Each time zone is represented by a binary file in the TZif format, containing:

  • Transition times: The moments when the time zone rules change
  • Time type information: UTC offsets, daylight saving flags, and abbreviation indices
  • Leap second data: For systems that track leap seconds
  • A POSIX-style TZ string: For predicting future transitions

A single time zone file might contain hundreds of historical transitions. The Europe/London zone, for example, has undergone dozens of rule changes since 1847, when railway time first standardized British clocks.

The Lawsuit That Threatened Global Time

In September 2011, the entire world’s time infrastructure faced an existential threat. An astrology software company called Astrolabe filed a lawsuit against Arthur David Olson and Paul Eggert, the maintainers of the timezone database, claiming copyright infringement.

Astrolabe argued that the historical time zone data in the database was derived from their “ACS Atlas” product, and that Olson and Eggert had illegally copied it. The company demanded that the database be taken down and sought damages.

The consequences were immediate. On October 6, 2011, the timezone database was removed from its longtime home at the U.S. National Institutes of Health. For several months, the world’s computers had no authoritative source for time zone updates.

The lawsuit was eventually dismissed in February 2012, but the incident revealed the fragility of global time infrastructure. The database had been maintained by two individuals, funded by no one, with no formal governance. The internet’s time depended entirely on volunteer labor.

Following the crisis, the database was transferred to IANA (Internet Assigned Numbers Authority), the organization that manages domain names and IP addresses. Today, Paul Eggert serves as the TZ Coordinator—a single person responsible for the time data used by virtually every computer system on Earth.

The Geographic Absurdities

Time zones are not clean lines of longitude. They’re shaped by politics, history, and sometimes pure whimsy.

China spans five natural time zones but uses only one. In 1949, the Communist government standardized the entire country on Beijing Time (UTC+8). In westernmost Xinjiang, the sun doesn’t rise until 10:00 AM in winter. Locals have developed an unofficial “Xinjiang Time” (UTC+6), leading to constant confusion between official and local time.

Nepal’s time zone is UTC+5:45—one of only three places on Earth using a 45-minute offset. The offset was chosen to match the local mean time in Kathmandu, which is approximately 5 hours and 41 minutes ahead of UTC. The 45-minute approximation was deemed close enough.

Kiribati jumped an entire day in 1995. This Pacific island nation straddled the International Date Line, with its eastern islands a day behind its western islands. To unify the country for business purposes, Kiribati moved its eastern islands across the date line—making Caroline Island the first place on Earth to see the new millennium.

Samoa lost December 30, 2011. In a single day, Samoa moved from UTC-11 to UTC+13, crossing the International Date Line. December 30, 2011 simply never happened in Samoa. The country did this to align with Australia and New Zealand, its major trading partners. A century earlier, Samoa had crossed the date line in the opposite direction for the same reason—to align with the United States.

The Leap Second Problem

The 2012 incident wasn’t the first time leap seconds caused chaos, and it wouldn’t be the last. Leap seconds exist because the Earth’s rotation is gradually slowing down due to tidal friction. Atomic clocks, however, tick at a constant rate. Without correction, atomic time would gradually diverge from solar time.

Since 1972, 27 leap seconds have been added to UTC. Each one has the potential to break software that doesn’t handle it correctly.

The problem is that Unix time—the number of seconds since January 1, 1970—doesn’t count leap seconds. Unix time assumes every day has exactly 86,400 seconds. When a leap second occurs, Unix systems have to do something strange: either repeat a second (making 23:59:59 occur twice) or step the clock backward (creating an apparent time reversal).

This breaks fundamental assumptions in software:

// This code assumes time always moves forward
if (end_time > start_time) {
    duration = end_time - start_time;
}

During a leap second, this assumption fails. A process starting at 23:59:59 and ending after the leap second might calculate a negative duration.

Google’s solution is “leap smear”—gradually spreading the extra second over 24 hours before the actual leap second. Each second becomes slightly longer, so that by the end of the day, the total adjustment equals one second. This avoids the discontinuity but means Google’s time is never exactly UTC during the smear period.

Other organizations handle leap seconds differently. Some shut down systems entirely. Some use TAI (International Atomic Time) internally and convert to UTC only for display. There is no standard approach.

In November 2022, the General Conference on Weights and Measures voted to abolish leap seconds by 2035. The decision ends decades of debate but creates new problems: UTC will gradually diverge from solar time, eventually requiring some larger correction.

The Year 2038 Problem

While leap seconds are an acute problem, a more predictable crisis looms. On January 19, 2038, at 03:14:08 UTC, Unix systems using 32-bit signed integers for time will overflow.

Unix time counts seconds since January 1, 1970. A signed 32-bit integer can represent values from -2,147,483,648 to 2,147,483,647. The maximum positive value corresponds to January 19, 2038. After that, the counter wraps to a negative number, representing December 13, 1901.

Systems still using 32-bit time at that moment will experience catastrophic failures. Files might appear to be from the future—or from 1901. Scheduling systems will break. Security certificates will appear invalid.

The solution is straightforward: use 64-bit integers. But finding and updating every 32-bit time value in every system worldwide is an enormous undertaking. Unlike Y2K, which had a fixed deadline that forced action, the 2038 problem can be deferred—and thus may be ignored until it’s too late.

Falsehoods Programmers Believe About Time

The complexity of timekeeping has spawned a famous list of “falsehoods programmers believe about time.” Some highlights:

  • “There are always 24 hours in a day.” (False: days with leap seconds have 86,401 seconds)
  • “Months have either 30 or 31 days.” (False: February has 28 or 29)
  • “Any 24-hour period will always begin and end in the same day.” (False: DST transitions)
  • “The server clock and the client clock will always be set to the same time.” (False: clock drift, timezone differences)
  • “A minute on the system clock has exactly the same duration as one minute on any other clock.” (False: clock drift, NTP adjustments)
  • “Time has no beginning and no end.” (False: Unix time has limits; so does the universe)
  • “The smallest unit of time is one second.” (False: milliseconds, microseconds, nanoseconds)
  • “Human-readable dates can be specified in universally understood formats such as 05/07/11.” (False: is this May 7 or July 5? 2011 or 2005?)

Each of these assumptions has caused real bugs in production systems.

Best Practices for Time in Software

Given the complexity, how should developers handle time correctly?

Store everything in UTC. This is the most common advice, and it’s generally sound. UTC has no daylight saving time, no political changes to offsets, and no local interpretation. A timestamp in UTC represents a unique moment in time.

But UTC alone is not sufficient. If a user schedules a meeting for “2 PM every Tuesday,” storing UTC timestamps won’t work correctly. When DST changes, 2 PM local time might shift from UTC+1 to UTC+2. The UTC time would need to change, but a stored UTC timestamp is static.

The solution is to store both the UTC time and the time zone identifier (e.g., “America/New_York” not “EST”). The timezone identifier allows converting the local time to the correct UTC time for any historical moment.

Never use offsets as identifiers. An offset like UTC-5 tells you nothing about what time zone a user is in. Both Chicago and Bogotá are UTC-5, but Chicago observes DST while Bogotá does not. A user specifying UTC-5 could mean either. The correct approach is to use IANA timezone identifiers like “America/Chicago” or “America/Bogota.”

Beware of ambiguous times. When DST ends and clocks fall back, the same local time occurs twice. In New York, 1:30 AM on the first Sunday of November happens twice—once in EDT (UTC-4) and once in EST (UTC-5). Without additional information, a local time like “1:30 AM November 5, 2023” in New York is ambiguous.

Beware of non-existent times. When DST starts and clocks spring forward, an hour of local time doesn’t exist. 2:30 AM on the second Sunday of March in New York never happens—the clock jumps from 1:59:59 AM EST directly to 3:00:00 AM EDT.

The Ongoing Maintenance Burden

Time zones are not static. Governments change rules with little notice. In 2016, Turkey announced just three weeks in advance that it would not end daylight saving time as expected. The IANA database had to be updated, and every system using it needed to download the update.

The database typically receives 10-20 updates per year. Some years see more: 2022 had 11 releases. Each update must be propagated to operating systems, programming language libraries, and applications. Users who don’t update their systems operate with outdated time rules.

The maintenance burden is significant. Paul Eggert, the current TZ Coordinator, tracks changes to time rules worldwide by monitoring news reports, government announcements, and mailing list submissions. The process is largely manual. There is no automated feed of global time policy changes.

The Fundamental Challenge

Time is unique among software engineering problems because it involves three incompatible systems:

  1. Physics: Earth’s rotation, which is irregular and unpredictable
  2. Politics: Time zone rules, which change arbitrarily
  3. Engineering: Computer representations, which have finite precision

These systems can never be fully reconciled. Any software that deals with time must navigate trade-offs among them.

The next time you write code that handles dates or times, remember: you’re not just manipulating numbers. You’re interfacing with centuries of human convention, political decisions, and the physical reality of a planet that doesn’t quite cooperate with our desire for neat, regular timekeeping.

That meeting scheduled for 2 PM might not happen at the time you expect. That log entry from “yesterday” might be from a different calendar day. That calculation of elapsed time might be off by a leap second. Time is not a solved problem—it’s an ongoing negotiation between humans, computers, and the universe.

References

  1. Metz, C. (2012). “The Inside Story of the Extra Second That Crashed the Web.” Wired. https://www.wired.com/2012/07/leap-second-glitch-explained/

  2. Wikipedia. “Leap second.” https://en.wikipedia.org/wiki/Leap_second

  3. Wikipedia. “tz database.” https://en.wikipedia.org/wiki/Tz_database

  4. IANA. “Time Zone Database.” https://www.iana.org/time-zones

  5. Colebourne, S. (2011). “Time zone database rebooted.” https://blog.joda.org/2011/10/time-zone-database-rebooted.html

  6. Computerworld. (2012). “Time runs out for timezone lawsuit.” https://www.computerworld.com/article/1454921/time-runs-out-for-timezone-lawsuit.html

  7. EFF. (2012). “Just the Facts: Lawsuit Against TimeZone Database Deserves Sanctions.” https://www.eff.org/deeplinks/2012/01/just-facts-lawsuit-against-timezone-database-deserves-sanctions

  8. Google. (2011). “Time, technology and leaping seconds.” https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-sessions.html

  9. Google Developers. “Leap Smear.” https://developers.google.com/time/smear

  10. BBC News. (2011). “Samoa and Tokelau skip a day for dateline change.” https://www.bbc.com/news/world-asia-16351377

  11. timeanddate.com. (2016). “Turkey Stays on Daylight Saving Time for Good.” https://www.timeanddate.com/news/time/turkey-scraps-dst-2016.html

  12. Smithsonian Magazine. (2011). “Sandford Fleming Sets the World’s Clock.” https://www.smithsonianmag.com/smithsonian-institution/sandford-fleming-sets-the-worlds-clock-389930/

  13. Canadian Geographic. (2017). “How Sandford Fleming changed the way the world experiences time.” https://canadiangeographic.ca/articles/how-sandford-fleming-changed-the-way-the-world-experiences-time/

  14. Nelson, G. (2017). “tzfile(5) - Linux manual page.” https://man7.org/linux/man-pages/man5/tzfile.5.html

  15. IETF. “RFC 8536 - The Time Zone Information Format (TZif).” https://datatracker.ietf.org/doc/html/rfc8536

  16. Sussman, N. (2012). “Falsehoods programmers believe about time.” https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

  17. Wikipedia. “Year 2038 problem.” https://en.wikipedia.org/wiki/Year_2038_problem

  18. Nature. (2022). “The leap second’s time is up: world votes to stop pausing clocks.” https://www.nature.com/articles/d41586-022-03783-5

  19. Medium. (2021). “The Largely Untold Story Of How One Guy In California Keeps The World’s Computers On The Right Time.” https://onezero.medium.com/the-largely-untold-story-of-how-one-guy-in-california-keeps-the-worlds-computers-on-the-right-time-a97a5493bf73

  20. Udell, J. (2009). “A literary appreciation of the Olson/Zoneinfo/tz database.” https://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzoneinfotz-database/

  21. timeanddate.com. “Why Is There Only One Time Zone in China?” https://www.timeanddate.com/time/china/one-time-zone.html

  22. New York Times. (2016). “Rise at 11? China’s Single Time Zone Means Keeping Odd Hours.” https://www.nytimes.com/2016/06/17/world/asia/china-single-time-zone.html

  23. Wikipedia. “International Date Line.” https://en.wikipedia.org/wiki/International_Date_Line

  24. Wikipedia. “List of UTC offsets.” https://en.wikipedia.org/wiki/List_of_UTC_offsets

  25. CityMonitor. (2022). “The world’s weirdest time zones.” https://www.citymonitor.ai/analysis/the-worlds-weirdest-time-zones/

  26. NIST. “Leap second and UT1-UTC information.” https://www.nist.gov/pml/time-and-frequency-division/time-realization/leap-seconds

  27. Lick Observatory. “Future of Leap Seconds.” https://www.ucolick.org/~sla/leapsecs/

  28. Stack Overflow. “Unix time and leap seconds.” https://stackoverflow.com/questions/16539436/unix-time-and-leap-seconds

  29. Qz. “Why China’s single time zone is a problem.” https://qz.com/144230/why-chinas-single-time-zone-is-a-problem

  30. Trussel.com. “Millenium: Date Line Politics - How did the Republic of Kiribati…” https://www.trussel.com/kir/dateline.htm