Your system clock drifts the moment it leaves the factory. A cheap crystal oscillator loses a couple of seconds a day. A machine running 24/7 can be off by minutes within a month, and that is enough to break TLS handshakes, corrupt database write orders, or stamp a log entry with a time that never happened. The correction mechanism is the Network Time Protocol, and it does far more than ask a remote machine "what time is it?"
NTP synchronizes clocks across packet-switched links by continuously steering your local oscillator toward a hierarchy of atomic and GPS-derived references. It never just fetches a value. It measures path latency, computes the clock offset, then slews your timebase forward or backward in sub-millisecond increments so your machine agrees with the rest of the world.
The part most people miss: your computer distrusts the first answer. It sends a small packet to a time source, stamps the departure, waits for the reply, stamps the arrival. From those four marks NTP derives both the round-trip delay and the exact offset between your clock and the remote. It applies a correction, then repeats the whole cycle periodically. The result is a clock accurate to within 10 milliseconds on a typical internet link, and under 1 millisecond on a local segment. That is not a guess. It is the protocol's design target.
What NTP is and why it matters
NTP is the internet's timekeeper. It has been running since 1985, making it one of the oldest protocols still in daily use. It operates on virtually every host, router, and operating system. When you read a timestamp in a log file, when your email client checks a certificate's validity window, when a database orders transactions, NTP is the invisible mechanism lining up the numbers.
Why does it matter? Because machines use timestamps for more than displaying the hour. Cryptographic signatures depend on the current instant to validate certificates. Distributed systems use timestamps to order events. Databases use them to resolve conflicts. A clock off by even one second can get you rejected from a TLS handshake, fail a file sync, or log an event in the wrong sequence.
The protocol is resilient by design. If one time source goes dark, your system tries another. If the path is congested, NTP discards the bad samples and uses only the reliable ones. It is self-correcting, fault-tolerant, and remarkably good at its job.
How NTP syncs your clock: stratum, delay, and offset
The NTP hierarchy is organized into layers called strata. A stratum 0 device is the authoritative source itself: an atomic clock, a GPS receiver, or a radio clock. Stratum 1 machines connect directly to those sources. Stratum 2 sync to stratum 1, and so on down the chain.
Your computer, whatever stratum it sits at, acts as a client. It sends a request to a peer, and the peer responds with its current time. But the response does not arrive instantly. It takes time to cross the link, and that delay matters.
NTP measures two quantities:
- Delay: the round-trip duration between your machine and the remote. Half of that is the one-way transit.
- Offset: the difference between your clock and the remote clock, corrected for delay.
The math is straightforward. Suppose you send a request at t0. The remote receives it at t1 and replies. You receive the reply at t2. The remote timestamp t1 is included in the reply. The round-trip delay is (t2 − t0) − (t1 − t0), and the offset is ((t1 − t0) + (t2 − t0)) / 2. NTP runs this calculation multiple times, filters outliers, and applies a weighted average.
The result is a smooth, continuous correction. NTP won't jerk your clock backward. That would break file timestamps and database sequences. Instead it slews the clock, adjusting by tiny fractions of a second per second until it converges on the correct instant.
NTP vs SNTP: full vs simple
SNTP stands for Simple Network Time Protocol. It is a stripped-down version.
SNTP does one thing: it fetches the time from a source and applies it immediately. No filtering, no statistical analysis, no complex error correction. A single request-response cycle. Good enough for devices that do not need high precision, like a smart thermostat or a digital camera.
Here is the catch: SNTP cannot handle jitter. If the link is slow or congested, the time you get might be off by hundreds of milliseconds. Fine for a wall clock. Not good enough for a host that must coordinate with other hosts.
NTP, by contrast, is built for precision. It maintains a history of past corrections, uses them to estimate the current error, and adjusts continuously. Running a production database, a trading system, or any application where timestamps must be reliable? Use full NTP. Just need to set the time once and do not care about the last few milliseconds? SNTP is adequate.
NTP vs PTP: when microseconds matter
NTP gets you to within milliseconds. PTP, the Precision Time Protocol, gets you to within microseconds, sometimes nanoseconds. That is a thousand to a million times finer.
PTP is used in financial trading, high-frequency trading, industrial automation, and broadcast media. It requires specialized hardware, typically a switch that timestamps packets in silicon rather than software. Hardware timestamping eliminates the variable delay NTP must work around.
Here is the trade-off: NTP works over the regular internet, through firewalls, and across arbitrary topologies. PTP generally works only on local area networks with PTP-aware switches. You cannot run PTP across the public internet and expect microsecond accuracy. The jitter is simply too large.
Which should you use? Running a home server or a small business setup, NTP is the right answer. It is free, built into every operating system, and accurate to a few milliseconds. PTP is for when milliseconds are not good enough and you are willing to invest in specialized hardware to get there.
Why your browser does not use NTP directly
If NTP is so effective, why won't your browser ask a time source what time it is? The answer is security, not capability.
Your browser reads the OS clock. When you load a webpage, JavaScript calls new Date() and gets the current instant from your operating system. The browser makes no request for the time. It does not trust a remote value. It trusts your OS clock, which NTP keeps in sync.
This is deliberate. If browsers accepted time from remote hosts, a malicious site could send a fake timestamp and trick your browser into accepting an expired certificate, or worse. By relying on the OS clock, browsers maintain a single, trusted time source.
The browser gets the instant from the OS clock. That is the key point. It does not ask for the time. It does not run NTP itself. It simply reads the system clock, which NTP has already synchronized. This separation of concerns keeps the browser simple and secure.
How to check if your clock is synced
You do not need to install anything. Every operating system includes a way to check sync status.
On Windows, open a command prompt and type w32tm /query /status. You will see the last sync time, the source, and the offset. On macOS, run sntp -sS time.apple.com to force a sync, or check System Settings under Date & Time. On Linux, timedatectl shows whether NTP is active, the current time, and the sync status.
To see the offset, how far off your clock is from the reference, run ntpdate -q on Linux or use ntpq -p to list the peers you are syncing to. A healthy system shows an offset under a few milliseconds. An offset above a second means your clock is either not syncing or you have a connectivity problem.
What happens when NTP is wrong or unavailable
When NTP fails, your clock drifts. The rate depends on your hardware. A typical computer clock loses a few seconds per day. Some drift by minutes per day if the oscillator is poor or the temperature fluctuates.
The consequences are rarely immediate, but they are real. Log files get timestamps that do not match other machines. Databases order transactions incorrectly. TLS certificates appear invalid because the system clock sits outside the validity window. In a distributed system, the whole thing can fall apart.
In the worst case, NTP can be actively malicious. If an attacker spoofs responses, they can push your clock backward or forward by hours. That is why modern systems use NTP authentication, NTS or symmetric keys, and why you should never trust an unencrypted response on an untrusted path.
The fix is simple: make sure NTP is enabled, point it at reliable sources, and monitor it. On a corporate setup, use the internal time infrastructure. At home, use the public NTP pools. The cost of failure is low. The cost of a wrong timestamp can be high.