How computers keep the right time
Every device you own is guessing what time it is. The part that counts the seconds is a vibrating sliver of quartz worth a few pence, and it is wrong — always, and by a little more every day. Everything from your bank card to a video call depends on that guess being quietly corrected, over and over, by machines you will never see.
The clock inside your device is worse than you think
There is no clock in your laptop in the sense you would recognise. There is a crystal that vibrates when you put a voltage across it, and a counter that adds one every time it has vibrated a set number of times. That is the whole mechanism, and it is not very good.
A quartz crystal is cut so that it flexes at a predictable rate — in most digital devices, 32,768 times a second. That number is not arbitrary: it is 2 to the power of 15, so fifteen halvings of the signal take you from the raw vibration to exactly one pulse per second, using nothing but simple circuitry.
The problem is that the rate is only predictable, not correct. The crystal was cut very slightly wrong at the factory. It flexes faster when it is warm and slower when it is cold. It ages, and drifts further off every year it is powered. A typical consumer crystal is specified to within about 20 parts per million, which sounds reassuring until you turn it into a number that means something.
Why it gets worse when you use the machine
Crystal frequency changes with temperature, and the inside of a computer is not a stable environment. A laptop compiling code runs far hotter than the same laptop reading email, so its clock speeds up and slows down through the day depending on what you happen to be doing. This is why two identical machines on the same desk will disagree after a week, and why the disagreement is not a constant amount you could simply subtract.
Two clocks, not one
Your device actually keeps time in two different places, and confusing them causes a lot of misdiagnosed problems.
The RTC
A tiny real-time clock on the motherboard with its own battery. It only exists to remember roughly what time it was while the machine is off, and it is the least accurate clock in the building.
The system clock
A counter the operating system keeps in memory while it is running. This is the one applications read, the one that gets corrected over the network, and the one that matters.
At boot the system clock is set from the RTC, which gets it into the right ballpark — the right day, usually the right minute. Everything after that is correction. If you have ever replaced a dead motherboard battery and found the machine convinced it was 2012, you have met the RTC failing at its only job.
The takeaway No computer knows what time it is. It counts vibrations from a cheap crystal that is wrong in a way that changes with temperature, and then spends its whole life being corrected by something better.
What the right time even means
Before anything can be corrected, there has to be something to correct it towards. That turns out to be a surprisingly political question, because the two obvious answers — the rotation of the Earth and the vibration of a caesium atom — do not agree, and the gap between them keeps growing.
A second used to be an astronomical quantity
For most of history a second was defined by dividing up a day: one 86,400th of the time it takes the Earth to spin once. That definition is intuitive and, it turns out, useless for precision work, because the Earth is not a reliable clock. It is slowing down as the Moon drags on the tides, and it speeds up and slows down unpredictably as mass sloshes around in its core and its oceans.
Since 1967 the second has been defined by the atom instead. One second is 9,192,631,770 oscillations of the radiation emitted by a caesium-133 atom moving between two particular energy states. Every caesium atom in the universe behaves identically, which makes this a definition anyone can reproduce in a laboratory without reference to anything else.
TAI, UT1 and UTC
TAI
International Atomic Time. The weighted average of some 450 atomic clocks in about 80 laboratories worldwide. It ticks perfectly and never stops. It also slowly drifts away from daylight.
UT1
Time according to the actual orientation of the Earth, measured by pointing radio telescopes at distant quasars. It matches the Sun, and it is irregular.
UTC
Coordinated Universal Time. Ticks at the atomic rate, but occasionally has a second inserted to keep it within 0.9 seconds of UT1. This is the one your devices use.
UTC is what every computer, network and standards body means by 'the time'. Your local time is UTC plus or minus an offset that your device applies at the very last moment, purely for display. Internally, almost everything works in UTC and converts only when it has to show a human a number.
The leap second, and why it is being abolished
Because the Earth's rotation is irregular, UTC has had 27 extra seconds inserted since 1972 — a minute that runs from :58 to :59 to :60 before rolling over. Every one of these has caused outages somewhere, because an enormous amount of software was written on the assumption that a minute has sixty seconds and that time only ever moves forwards.
Large operators eventually stopped trying to implement leap seconds correctly and started smearing them instead: spreading the extra second across a whole day as a tiny slowdown, so that no clock ever repeats or jumps. The downside is that a smeared machine and an unsmeared machine disagree by up to a second for that day, which is its own category of problem.
In 2022 the international body responsible voted to stop adding leap seconds by 2035 and to let UTC drift away from the Sun instead. The reasoning was simple: the difference will take centuries to become noticeable to a human, and it has been breaking computers every few years.
The takeaway The reference everything aims at is UTC: atomic ticks, occasionally nudged to keep pace with a planet that does not keep good time. The nudging is being phased out because it has caused more trouble than the drift it corrects.
Asking something that knows better
Correcting a bad clock from a good one over a network sounds trivial — ask what time it is, set your clock to the answer. It is not trivial, because the answer takes time to arrive, and by the time you read it, it is already wrong by an unknown amount.
This is the entire problem the Network Time Protocol exists to solve, and its solution is elegant enough to be worth understanding properly. NTP does not ask what time it is. It records four timestamps and does arithmetic on them.
Why four timestamps and not two
If you only knew when you sent the request and when the reply arrived, you could measure the round trip but you could not tell how much of it was the server thinking. By including its own receive and transmit times, the server lets the client subtract that portion out. What remains is the genuine network delay.
NTP then makes one assumption, and it is the protocol's single weak point: it assumes the path was symmetric, that the request took as long to get there as the reply took to come back. Halving the remaining delay gives the one-way trip, which is the amount the server's timestamp needs adjusting by. When that assumption holds, the result is accurate to a few milliseconds over the public internet.
It steers the clock rather than setting it
Having worked out that it is 40 milliseconds fast, a well-behaved machine does not simply subtract 40 milliseconds. Jumping a clock backwards means the same timestamp occurs twice, which corrupts logs, confuses databases and can make file modification times appear in the future. Instead the operating system is told to run the clock fractionally slower until the error has been absorbed. This is called slewing, and to anything reading the clock the correction is invisible.
Slewing is only used for small errors. If the clock is out by more than 128 milliseconds NTP will step it, and if it is out by more than about 17 minutes most implementations will refuse to do anything at all and log a panic, on the grounds that something is so badly wrong that silently changing the time could be worse than leaving it alone.
It also learns the crystal's personality
Because the same machine is corrected again and again, NTP can see a pattern: this crystal consistently runs 12 parts per million fast. It writes that down and applies a permanent frequency correction, so the clock stays close even between checks — and even if the network disappears for a while. A machine that has been up for months has effectively been calibrated against an atomic clock.
| Situation | What NTP does |
|---|---|
| Off by a few milliseconds | Slew — run slightly fast or slow until corrected |
| Off by more than 128 ms | Step — jump the clock, accepting the disruption |
| Off by more than ~17 minutes | Refuse and alert; something is badly wrong |
| Consistently drifting one way | Record the drift rate and correct it permanently |
The takeaway NTP's insight is that you cannot trust an answer that took an unknown time to arrive — so measure how long it took, subtract it, and then apply the correction so gently that nothing notices.
Stratums: how far you are from an actual clock
Not every time server is equally trustworthy, and NTP is explicit about it. Every server advertises a single number saying how many hops it is from a genuine reference clock. That number is its stratum, and it exists to stop the whole system quietly disappearing up its own reasoning.
What a stratum 0 device actually is
Stratum 0 is not a computer. It is the physical thing producing the time, and it never appears on the network itself — it is wired into a stratum 1 server, usually over a dedicated serial line or a single pulse-per-second cable.
GPS receiver
Every GPS satellite carries atomic clocks and broadcasts the time continuously. A receiver with a clear view of the sky is a cheap, extremely accurate reference — which is why so much timing infrastructure has an aerial on the roof.
Caesium standard
The kind of clock that defines the second. Expensive, and used by national measurement institutes and by operators who cannot depend on receiving a signal from space.
Radio time signal
Long-wave transmissions such as MSF in the UK or DCF77 in Germany. This is what a 'radio controlled' wall clock listens to.
Rubidium oscillator
Not accurate enough to define anything, but stable enough to hold good time for days if its reference vanishes — used as a holdover clock in phone networks.
Why the counting matters
The stratum number exists to prevent loops. Without it, two servers could end up taking their time from each other, drifting away together in perfect agreement and total error, with nothing in the system able to notice. By insisting that a server's stratum is always one more than whatever it is following, and by capping the chain at 15, NTP guarantees that every clock is traceable back to something real.
Where your devices actually get it
Almost nothing queries a stratum 1 server directly, and you should not try. Public pools exist precisely so that load is spread across thousands of volunteer servers, and operating system vendors run their own.
| Client | Typically asks |
|---|---|
| Windows PC | time.windows.com, or a domain controller on a company network |
| Mac / iPhone | time.apple.com |
| Android phone | Google's time servers, plus the mobile network |
| Linux server | The NTP Pool Project, or the distribution's own pool |
| Home router | A pool server; it then serves time to devices on your network |
| Domain-joined PC | Its domain controller — mandatory, not optional |
The takeaway Stratum counts hops, not quality. Its real job is to guarantee that every clock on the internet has an unbroken chain back to a physical reference, with no possibility of a circular argument.
Why a wrong clock breaks the secure web
The most common way an ordinary person discovers their clock is wrong is that the internet stops working. Not slowly, and not partially — every secure site at once starts throwing security warnings, which is alarming and looks nothing like a clock problem.
A TLS certificate is a signed statement that a particular public key belongs to a particular domain name. Crucially, that statement is only valid between two dates written inside it. A certificate issued today and valid for 90 days carries both the start and the end, and every client that sees it checks the current time against them.
Why it fails so completely
There is no way for the browser to tell the difference between 'my clock is wrong' and 'someone is presenting me an old, revoked certificate they stole last year'. The second possibility is exactly the attack that expiry dates exist to prevent, so the browser has to assume the worst. Being lenient here would undermine the whole point of having an expiry date.
This is also why the failure is so total. Every certificate on the internet has dates, so every secure connection fails simultaneously — which, these days, means effectively everything, including the connection your device would use to go and fetch the correct time.
The bootstrapping problem
That last point is a genuine chicken-and-egg problem. If your clock is so wrong that HTTPS fails, and the time service you would use runs over HTTPS, you cannot recover without help. This is one of several reasons plain NTP is not encrypted and runs over its own simple protocol on UDP port 123: it has to work when nothing else does.
The trade-off is that unauthenticated NTP can be tampered with by anyone in the path, and deliberately feeding a machine the wrong time is a real attack — push a clock forward far enough and expired, revoked certificates become acceptable again. NTS (Network Time Security) exists to fix this, using cryptography to authenticate time responses without needing a correct clock to begin with.
| Symptom | Likely clock cause |
|---|---|
| Every HTTPS site warns at once | System clock wrong by months or years |
| One site warns, others fine | That site's certificate genuinely expired |
| Logins fail with no obvious error | Clock out by minutes — token or Kerberos window missed |
| Works after a reboot, fails later | Time sync not running; crystal drifting freely |
| Wrong time after every power-off | Dead motherboard battery — the RTC forgets |
The takeaway Certificates are only valid between two dates, so a device with the wrong idea of the date cannot trust anything. It is the single most common way a clock problem announces itself, and it never looks like one.
Why distributed systems care even more
A browser needs the date to be roughly right. A database spread across three continents needs something much harder: agreement about the order in which things happened, on machines that have never met and whose clocks disagree.
Consider two people editing the same record, one in London and one in Singapore, at what each machine believes is the same instant. The system has to decide which change came second and therefore wins. If the two servers' clocks disagree by half a second, the system can easily conclude that the earlier edit happened later — and silently keep the wrong one.
The usual answer: give up on wall-clock time
The traditional response is to stop trusting clocks entirely and track causality instead. A logical clock is just a counter that increments on every event, passed along with every message. It cannot tell you what time anything happened, but it can tell you reliably that A definitely happened before B, which is usually the question that actually matters.
Lamport clock
One number per node, bumped on each event and carried on each message. Cheap, and enough to give every event a consistent order everyone agrees on.
Vector clock
One counter per node, carried together. Larger, but it can also detect that two events were genuinely concurrent — that neither caused the other.
HLC
Hybrid logical clocks combine a physical timestamp with a counter, so the values still look like real times to a human while keeping the ordering guarantees.
The other answer: bound the uncertainty
Google's Spanner took a different approach that is worth knowing about because it inverts the usual assumption. Rather than pretending its clocks are correct, every machine reports the time as an interval — 'it is somewhere between these two instants' — with the width of that interval derived from how long it has been since the last sync and how fast the local crystal is known to drift.
To commit a transaction, the system simply waits until the uncertainty interval has passed before declaring it done. That deliberate pause guarantees that any transaction starting afterwards anywhere in the world will see a later timestamp. The cost is a few milliseconds of added latency on every write; the benefit is a globally distributed database that behaves as if it had one clock.
Making that interval narrow enough to be practical is why those data centres contain GPS receivers and atomic clocks. The exotic hardware is not there for accuracy as such — it is there to keep the uncertainty small enough that the waiting is short.
Where else it bites
| System | What a clock disagreement causes |
|---|---|
| Log aggregation | Events from different servers interleave in the wrong order |
| Kerberos / Active Directory | Authentication refused outright beyond ~5 minutes skew |
| TOTP two-factor codes | Codes rejected as the 30-second window misaligns |
| Distributed locks | A lock believed expired by one node and held by another |
| Certificate issuance | Certificates issued with a start time in the future |
| Financial trading | Regulators require timestamps traceable to UTC by law |
The takeaway Single machines need the right time to be trusted. Groups of machines need something stricter — agreement about order — and the engineering effort goes into either avoiding wall-clock time or making its uncertainty small and explicit.
When milliseconds are nowhere near good enough
NTP over the internet gets you within a few milliseconds, which is fine for almost everything. A handful of industries need to be a thousand times better than that, and for them the entire approach has to change.
The limit on NTP is not the protocol's arithmetic — it is that timestamps are taken in software. Between a packet arriving at the network card and the operating system noting the time, there is an unpredictable delay: interrupts, scheduling, other processes. That jitter is small, but it is larger than the precision these industries need.
PTP moves the timestamping into the hardware
The Precision Time Protocol takes the timestamp in the network card itself, at the moment the packet crosses the wire, before any software is involved. More importantly, the switches along the path participate: each one measures how long it held the packet and writes that figure into a correction field as it passes.
Who needs this
Trading venues
European rules require timestamps traceable to UTC within 100 microseconds for high-frequency trading, so that the sequence of orders can be reconstructed by a regulator afterwards.
Mobile masts
The scheduler in a 5G cell hands out slots lasting fractions of a millisecond. Neighbouring masts must agree on slot boundaries or they interfere with each other.
Live production
Video and audio from many cameras and desks must stay aligned to within a fraction of a frame, which is why studios distribute time over their own network.
Power grids
Protection equipment compares the phase of the current at both ends of a transmission line. Getting the timing wrong means misreading a fault.
Radio astronomy
Telescopes on different continents combine their signals as though they were one enormous dish, which only works if each one timestamps its data to the nanosecond.
Holdover: what happens when the reference goes
Anything depending on GPS has to plan for losing it — jamming, a failed aerial, a building in the way. The answer is holdover: a local oscillator good enough to keep time on its own for hours or days while the reference is missing. A rubidium oscillator might hold a microsecond for a day; a caesium standard far longer. This is one of the rare cases where the expensive clock earns its price not when things are working, but when they are not.
The takeaway Past the millisecond mark, software timestamps are the limit. PTP solves it by timestamping in hardware and making every switch on the path declare how long it held the packet.
What actually goes wrong in practice
Having established that the hard part is physics, it is worth ending with the uncomfortable truth: almost every time-related bug that reaches a user is not about accuracy at all. It is about what happens after the correct instant has been handed to a programmer.
An instant and a local time are different things
A moment in time is a single unambiguous number — seconds since an agreed epoch, the same everywhere in the universe. A local time is that number rendered for a human in a particular place, under rules set by that place's government, which can and do change with a few weeks' notice.
The rule that follows is simple and endlessly ignored: store the instant, apply the zone at the last possible moment. Storing '14:00' without a zone loses information that cannot be recovered, and storing a future appointment as UTC loses information too — because if the government moves the clocks between now and then, the meeting was always meant to be at 2pm local, not at that particular UTC instant.
| What you are storing | Store it as |
|---|---|
| When something happened | UTC instant — it is a fact and will not change |
| A future meeting | Local time plus the zone name, e.g. Europe/London |
| A recurring daily alarm | Wall-clock time plus zone; the offset will move |
| A log entry | UTC, always, with the offset recorded if you need it |
| A birthday | A plain date with no time or zone at all |
The clocks going back is the interesting one
When the clocks go forward, an hour simply does not exist — 01:30 never happens, and anything scheduled then has to be moved. When they go back, the worse case, an hour happens twice. Ask a machine to convert 01:30 local to an instant on that night and there are two correct answers. A scheduled job can run twice; a reading taken every hour arrives out of order; a database index built on local time acquires duplicates.
The zone database is a living thing
Time zone rules are maintained in the IANA time zone database, updated several times a year as countries change their minds. Devices that stop receiving updates eventually get the wrong local time, not because their clock drifted but because the rules moved underneath them. This is why an old phone can show the right time everywhere except for a couple of weeks around a transition.
The database uses place names rather than offsets for exactly this reason.
Europe/London is a set of rules that has changed many times and will
change again; GMT+1 is a fixed offset with no rules at all, and using
it for a future date is almost always a mistake.
A short list that avoids most of the pain
- Keep the system clock synchronised, and monitor that it is — a silently dead time service looks exactly like a working one until it does not.
- Work in UTC internally, everywhere, without exception.
- Convert to local time only when displaying to a person, and use a zone name.
- Never assume a day has 24 hours, a minute has 60 seconds, or that time only moves forwards.
- Use the platform's time zone library rather than arithmetic on offsets; the rules are far more irregular than they look.
- Test explicitly against the two transition nights — most time bugs are discovered by users at 2am twice a year.
The takeaway Eight steps, atomic clocks, satellites overhead and hardware timestamping in network cards — and the thing most likely to break is someone storing a meeting time without recording which country it was in.