The problem before NTP
Before the internet learned to tell time, every computer was on its own. A server in New York might drift three minutes fast over a week. A database replica in San Francisco might run two minutes slow. A trading terminal in Chicago might disagree with both. Nobody noticed when machines worked in isolation, but the moment they started talking to each other, the chaos became impossible to ignore.
Time matters more than most people realize. Financial exchanges need to know which trade came first. When two database servers replicate data between each other, they use timestamps to decide which write wins. Log files from different machines need to be merged in chronological order so engineers can debug outages. Air traffic control systems, hospital medication dispensers, power grid synchronizers, certificate authorities that issue the encryption keys behind every HTTPS connection — all of them depend on clocks that agree.
In the early 1980s, the internet was still a collection of university and government networks, but already the problem was acute. Machines synced their clocks by calling timekeeping services over modem lines, a process that was slow, expensive, and wildly inaccurate. Some administrators set clocks by hand, glancing at a wristwatch and typing in the time. The error could be seconds, minutes, or worse. What the growing network needed was a protocol — an automatic, self-correcting way for every machine on the internet to agree on what time it was.
David Mills and the birth of NTP
The person who solved this problem was David L. Mills, a computer science professor at the University of Delaware. Mills had been thinking about network timekeeping since the late 1970s, and in 1985 he published RFC 958, the first formal specification of the Network Time Protocol. It was not his first attempt at the problem — he had designed earlier protocols called DCNET and the Internet Clock Service — but NTP was the one that stuck.
RFC 958 laid out an architecture that was simultaneously elegant and practical. Instead of requiring every computer to reach an atomic clock directly, NTP organized time sources into a hierarchy. It used clever mathematics to compensate for unpredictable network delays. And it was designed to be robust: if one time source went down, clients would automatically switch to another. The protocol could synchronize clocks across the chaotic, unreliable internet of the 1980s to within tens of milliseconds — an achievement that seemed almost magical at the time.
Mills maintained and evolved NTP for nearly three decades, almost single-handedly. He wrote the reference implementation. He answered questions on mailing lists. He published updated RFCs as the protocol matured through versions 2, 3, and 4. By the time he retired, NTP had become one of the oldest internet protocols still in active daily use, older than HTTP, older than SSL, older than DNS as we know it today. Mills passed away in January 2024 at the age of 85, leaving behind a protocol that quietly synchronizes billions of devices every day. Most of the people who depend on his work have never heard his name.
How the stratum system works
NTP organizes time sources into layers called strata. At the top sits Stratum 0: the actual timekeeping hardware. These are cesium atomic clocks, hydrogen masers, GPS receivers, and other precision instruments that produce a time signal accurate to billionths of a second. You cannot connect to a Stratum 0 device over the network — they are physical instruments, often bolted to racks in national laboratories or mounted on satellites orbiting 20,200 kilometers above the Earth.
Stratum 1 servers are computers directly connected to Stratum 0 hardware, typically via a serial cable, a dedicated GPS antenna on the roof, or a direct link to a cesium clock down the hall. These machines read the atomic time signal and make it available over the network. There are roughly a thousand public Stratum 1 servers in the world, operated by national metrology labs, universities, and technology companies.
Stratum 2 servers synchronize from Stratum 1. Stratum 3 from Stratum 2. Each layer adds a small amount of error and a small amount of delay. The hierarchy continues down to Stratum 15. Stratum 16 is a special value meaning "unsynchronized" — a server at Stratum 16 is advertising that it has no reliable time source and should not be trusted.
The genius of this layered design is load distribution. There are billions of devices on the internet that need accurate time, but only a few hundred atomic clocks. If every smartphone on Earth tried to sync directly from a cesium fountain at the National Institute of Standards and Technology in Boulder, Colorado, the system would collapse instantly. Instead, your phone syncs from a Stratum 2 or 3 server, which syncs from a Stratum 1, which syncs from the atomic clock. The load fans out across millions of intermediate servers, and the atomic clocks remain unbothered.
The clever math behind NTP
The fundamental challenge of network time synchronization is that you cannot simply ask a server "what time is it?" and use the answer. The question takes time to travel across the network. The answer takes time to travel back. And those two travel times are not necessarily equal — a packet might take 20 milliseconds to cross the Atlantic westbound and 35 milliseconds to return eastbound, depending on routing, congestion, and the phase of the moon.
NTP solves this with a four-timestamp exchange. The client records the time it sends a request (T1). The server records the time it receives that request (T2). The server records the time it sends its reply (T3). And the client records the time it receives that reply (T4). From these four numbers, NTP calculates two values that matter.
The round-trip delay is (T4 - T1) - (T3 - T2). This tells you how long the packet spent in transit, excluding the time the server spent processing the request. The clock offset is ((T2 - T1) + (T3 - T4)) / 2. This is the estimated difference between the client's clock and the server's clock, assuming the network delay is roughly symmetric in both directions.
That symmetry assumption is not always true, and NTP knows it. The protocol does not rely on a single exchange. It queries multiple servers, collects many samples over time, applies statistical filtering to discard outliers, and uses algorithms with names like the "clock selection algorithm" and the "clock clustering algorithm" to pick the best sources and combine them. The result, over the public internet with all its unpredictability, is synchronization accurate to a few milliseconds. On a local area network, where delays are short and stable, NTP routinely achieves accuracy below 100 microseconds.
Where the time actually comes from
At the very foundation of the timekeeping pyramid are the world's national metrology laboratories. The National Institute of Standards and Technology (NIST) in Boulder, Colorado operates a bank of cesium fountain clocks — devices that launch clouds of cesium atoms upward through a microwave cavity and measure their quantum state transitions as they fall back down. The oscillation frequency of cesium-133, exactly 9,192,631,770 cycles per second, has defined the SI second since 1967.
Germany's Physikalisch-Technische Bundesanstalt (PTB) in Braunschweig, the United Kingdom's National Physical Laboratory (NPL) in Teddington, France's LNE-SYRTE in Paris, and about 80 other national laboratories around the world maintain their own atomic clocks. Each lab produces its own realization of the second, and these realizations do not agree perfectly. A cesium clock in Boulder might differ from one in Braunschweig by a few nanoseconds over a month.
This is where the Bureau International des Poids et Mesures (BIPM) in Paris enters the picture. The BIPM does not keep a clock. Instead, it collects timing data from roughly 450 atomic clocks in about 80 laboratories worldwide, applies a weighted averaging algorithm, and publishes a paper timescale called Coordinated Universal Time, or UTC. This averaging process happens after the fact — the BIPM publishes corrections weeks later — so UTC is not available in real time. What you actually sync to via NTP is each laboratory's real-time approximation of UTC, called UTC(NIST), UTC(PTB), or similar. The BIPM's role is to keep all these approximations from drifting apart.
Then there are the GPS satellites. Each of the 31 operational GPS satellites carries multiple atomic clocks — rubidium and cesium — and broadcasts time signals as part of its navigation message. GPS time is not identical to UTC (it diverged in 1980 and does not include leap seconds), but the offset is broadcast in the navigation message, so a GPS receiver can compute UTC. Many Stratum 1 NTP servers use GPS as their reference clock because a $50 receiver and a rooftop antenna can deliver time accurate to within 10 nanoseconds, far cheaper than buying a cesium clock.
NTP at scale
The NTP Pool Project, hosted at pool.ntp.org, is one of the internet's great volunteer infrastructure stories. Started in 2003 by Adrian von Bidder, the pool is a collection of thousands of volunteer-operated NTP servers distributed across the globe. When your computer is configured to use pool.ntp.org, the DNS system returns a different set of server addresses each time, distributing the load across the volunteer pool. As of 2025, the pool serves an estimated 50 million clients per second and handles the time synchronization needs of most Linux distributions, many IoT devices, and countless other systems that use pool.ntp.org as their default NTP source.
Major technology companies run their own time infrastructure at enormous scale. Google operates a fleet of servers synchronized to atomic clocks and GPS receivers in its data centers. Google's time service is publicly available at time.google.com and implements an interesting twist: instead of inserting leap seconds abruptly, Google uses a technique called "leap smear," gradually spreading the extra second over a 24-hour window. This avoids the software crashes that sharp leap second insertions have historically caused, but it means that during a leap smear event, Google's time deliberately disagrees with UTC by up to half a second.
Meta (formerly Facebook) runs a similar internal time service and has published detailed engineering blog posts about its use of Precision Time Protocol (PTP) within its data centers, layered on top of GPS-disciplined grandmaster clocks. Amazon operates the Amazon Time Sync Service, available to all AWS instances. Cloudflare runs a public NTP service and has been an advocate for Roughtime, a protocol developed by Google that adds cryptographic proof to time responses so clients can verify they are not being deceived.
When NTP goes wrong
On June 30, 2012, a leap second was inserted into UTC at midnight. The extra second — 23:59:60 — caused the Linux kernel's timekeeping code to enter a bug that made the system's high-resolution timer go haywire. Processes that relied on these timers suddenly consumed 100 percent of their CPU cores, spinning in tight loops. Reddit went down. Mozilla went down. Gawker went down. Qantas Airlines' check-in system crashed, stranding passengers. StumbleUpon, FourSquare, Yelp, and LinkedIn all reported disruptions. The fix was either to restart the affected systems or to manually set the clock, which felt ironic given that the problem started with an attempt to keep clocks accurate.
GPS spoofing presents a more insidious threat. Because GPS signals arrive at extremely low power — about 10^-16 watts at the Earth's surface — they can be overwhelmed by a relatively inexpensive transmitter broadcasting fake signals. A spoofed GPS signal can feed false time to any Stratum 1 NTP server that uses GPS as its reference. In 2013, researchers at the University of Texas at Austin demonstrated that they could spoof a GPS receiver from a kilometer away using equipment costing about $3,000, gradually shifting the reported time without triggering any alarms.
In 2016, Cloudflare experienced a widely reported incident where some of its servers briefly returned dates in 2026 or 1970 to clients due to a bug in how they handled NTP. More subtle failures happen constantly. Misconfigured NTP servers that advertise themselves as Stratum 1 when they are actually free-running cause cascading inaccuracy in any client that trusts them. Firewalls that block NTP traffic leave machines to drift silently. Virtual machines in cloud environments are notorious for clock drift because the hypervisor's CPU scheduling introduces unpredictable delays in the guest operating system's timekeeping.
These failure modes explain why NTP authentication matters. The original NTP protocol had no way for a client to verify that a time response actually came from the server it claimed to be from. An attacker on the network path could alter time responses in transit. Network Time Security (NTS), specified in RFC 8915 and published in 2020, adds TLS-based authentication to NTP. Adoption has been slow — most NTP traffic on the internet is still unauthenticated — but major providers like Cloudflare now support NTS, and the trajectory is toward universal adoption.
GPS time vs. NTP
Your smartphone almost certainly does not use NTP as its primary time source. Instead, it uses the time broadcast by the cellular network, which is itself derived from GPS. GPS satellites carry onboard atomic clocks and broadcast their current time as part of every navigation signal. The receiver in your phone, in addition to computing your latitude and longitude, extracts the time from the satellite signals and uses it to set the phone's clock.
GPS time and UTC are not the same thing. When GPS was launched in 1980, it was synchronized to UTC. But UTC occasionally inserts leap seconds to stay aligned with the Earth's slowing rotation, and GPS does not. As of 2025, GPS time is 18 seconds ahead of UTC. The GPS navigation message includes the current offset, so receivers can convert between the two, but the distinction matters to engineers who work with raw GPS data.
Modern smartphones use a hybrid approach. The GPS or cellular time signal provides a coarse synchronization, typically accurate to within a few tens of nanoseconds. But GPS reception is intermittent — the phone may be indoors, in a subway, or in airplane mode. NTP fills the gaps. Apple, Google, and most phone manufacturers configure their devices to also query NTP servers (Apple uses time.apple.com, Android devices use time.android.com) to maintain accuracy when satellite signals are not available. The two systems complement each other: GPS provides absolute accuracy when the sky is visible, and NTP provides continuous correction when it is not.
The Y2038 problem
Unix time, the system used by virtually every server, phone, and embedded device on the planet, counts the number of seconds elapsed since midnight UTC on January 1, 1970. For decades, this count was stored as a signed 32-bit integer, which can hold values up to 2,147,483,647. That number of seconds after the Unix epoch corresponds to 03:14:07 UTC on January 19, 2038. One second later, the counter overflows, and systems still using 32-bit timestamps will interpret the date as December 13, 1901.
NTP has its own version of this problem. The NTP timestamp format uses a 64-bit value: 32 bits for the seconds since January 1, 1900, and 32 bits for the fractional second. The seconds field wraps around on February 7, 2036 — two years before the Unix Y2038 deadline. NTPv4, the current version of the protocol, handles this by defining "era numbers" that disambiguate which 136-year cycle a timestamp belongs to, but both endpoints must implement the era logic correctly.
Most modern servers, desktops, and phones already use 64-bit operating systems with 64-bit time representations, which will not overflow for approximately 292 billion years. The danger lies in the long tail of embedded systems: industrial controllers, building automation systems, medical devices, automotive ECUs, and the billions of IoT devices running 32-bit firmware that may never receive an update. Many of these devices use NTP to set their clocks. The quiet, unglamorous work of identifying and upgrading vulnerable systems is ongoing, but unlike Y2K, there is no single deadline that focuses public attention. The 2036 NTP rollover and the 2038 Unix rollover will arrive whether or not every last embedded thermostat and traffic light controller has been patched.
Forty years and counting
NTP has synchronized the internet's clocks for four decades. It survived the transition from ARPANET to the commercial internet, from dial-up to fiber, from mainframes to smartphones. David Mills designed a protocol so robust and so well-suited to its task that it has outlasted nearly everything it was originally built to serve. The machines have changed, the networks have changed, the speeds have increased by a factor of a million, and NTP still works.
But the demands on timekeeping are growing. 5G cellular networks require synchronization accurate to tens of nanoseconds between base stations. Autonomous vehicles need precise timing to fuse data from lidar, radar, and cameras. High-frequency trading firms measure latency in nanoseconds and will pay millions for a few microseconds of advantage. For these applications, NTP's millisecond-level accuracy is not enough. The Precision Time Protocol (PTP), defined in IEEE 1588, can achieve nanosecond-level synchronization on dedicated network hardware. PTP is already standard in telecommunications, broadcasting, and financial trading networks.
Yet for the billions of everyday devices — the laptop on your desk, the server in a data center, the thermostat on your wall, the camera in your doorbell — NTP remains the invisible backbone of synchronized time. It is one of those foundational internet protocols that works so well that almost nobody thinks about it. Every time you glance at the clock on your phone and it agrees with the clock on your laptop, which agrees with the clock on the wall at the airport, which agrees with the departure time on the flight status board, you are seeing the work of a protocol designed by a professor in Delaware four decades ago, ticking along without complaint, keeping the world in sync.