Local Clock Only vs Time Synchronization

Whether to trust a machine's own quartz clock or keep it disciplined against an external time source. One drifts. The other doesn't. This isn't a close call.

The verdict

Time synchronization wins, and it isn't close. A bare quartz crystal is a cheap oscillator that drifts with temperature, voltage, and age — expect 50 to 100 parts per million, which is several seconds per day, and worse when the room heats up. Local-clock-only means every machine in your system invents its own private timeline, and those timelines fan out from each other forever. That's fine until you need two computers to agree on anything: certificate validity, token expiry, replication ordering, a distributed lock. Time sync — chrony, NTP, or PTP for the demanding cases — disciplines the local clock against a reference and keeps it inside milliseconds. It is one of the cheapest, highest-leverage pieces of hygiene in all of computing. Skipping it to 'keep things simple' is how you earn a 3 a.m. page over an expired cert that wasn't actually expired. Sync, always, unless you physically cannot.

Why local-clock-only fails in practice

The failure mode isn't subtle, it's just delayed. Day one, everything works — the clock is roughly right because someone set it. Then it drifts. TLS handshakes start failing because your machine thinks the certificate isn't valid yet, or expired early. Kerberos, with its hard five-minute clock-skew tolerance, simply refuses to authenticate. JWTs reject as not-yet-valid. Your database replica applies events in an order that doesn't match reality, and your logs become unreadable because timestamps across hosts disagree by tens of seconds — try debugging a cascading outage when you can't trust which event came first. The cruelest part: each machine drifts independently, so there's no constant offset you can mentally subtract. It's not 'everyone is 12 seconds slow,' it's chaos. Local-clock-only is a debt that compounds silently and presents the bill during your worst incident. It buys nothing in exchange.

When the local clock is actually right

Credit where due: there's a narrow, legitimate case. A fully air-gapped device with no peers, no certificates, and no log correlation needs — an offline embedded controller, a piece of lab instrumentation, a sensor logging to its own local store — genuinely has nobody to disagree with. If there's no network and no GPS receiver, you cannot synchronize, so a battery-backed real-time clock, ideally a temperature-compensated TCXO, is your best available truth. Monotonic clocks are also the correct local tool for measuring elapsed durations — you should never use wall-clock time for a stopwatch, synced or not, because sync corrections can jump time backward. But notice the shape of every valid case: it's either 'I physically cannot sync' or 'I'm not measuring wall-clock time at all.' Nobody chooses local-clock-only for a networked system on purpose. It's a constraint you suffer, not a design you pick.

How to do sync right

Don't just type 'install ntpd' and walk away. Use chrony over legacy ntpd on Linux — it converges faster, handles intermittent connectivity and laptops that sleep, and steers the clock more smoothly. Point at multiple independent sources (at least three, ideally four) so a single bad server can't pull you off; a lone upstream is a single point of falsehood. For ordinary servers, NTP's millisecond accuracy is plenty. If you're doing financial trading timestamps, telecom, or sub-microsecond distributed coordination, that's PTP (IEEE 1588) territory, often with hardware timestamping and a GPS-disciplined grandmaster clock. Authenticate your time source where you can — NTS or signed sources — because an attacker who controls your clock can resurrect expired certificates and replay tokens. Monitor offset and drift as first-class metrics; an unmonitored sync daemon that silently died is just local-clock-only wearing a costume. Time is infrastructure. Treat it like infrastructure.

Quick Comparison

Factor	Local Clock Only	Time Synchronization
Accuracy over time	Drifts seconds/day (50-100 ppm), unbounded	Held to milliseconds (NTP) or sub-microsecond (PTP)
Fleet agreement	Every machine on its own private timeline	All nodes share one reference within ms
Setup cost	Zero — it's the default	Near-zero: install chrony, point at pools
Works air-gapped / no network	Yes — battery RTC is the only option	Needs network or GPS reference
Cert / token / Kerberos reliability	Breaks as drift exceeds skew tolerance	Stays inside skew windows indefinitely

The Verdict

Use Local Clock Only if: You have exactly one device, fully air-gapped, with no certificates, no distributed peers, and no need to correlate its logs against anything — a lab oscilloscope or an offline embedded controller where a battery-backed RTC is the only timekeeper available.

Use Time Synchronization if: You run literally anything networked: a server, a phone, a cluster, anything touching TLS, OAuth, Kerberos, databases, or logs you'll one day need to read in order.

Consider: Hardware constraints. If you genuinely have no network and no GPS, a temperature-compensated RTC (TCXO) plus periodic manual correction is your fallback — but that's local clock as a hostage situation, not a preference.

Local Clock Only vs Time Synchronization: FAQ

Is Local Clock Only or Time Synchronization better?

Time Synchronization is the Nice Pick. An uncorrected quartz oscillator drifts roughly 1 second per day — tens of seconds a month — and every machine drifts in a different direction, so your fleet has no shared notion of "now." The moment you have two computers, a TLS certificate, a JWT expiry, or a log you need to correlate, that disagreement becomes outages and security holes. Time sync (NTP/chrony/PTP) costs nearly nothing and removes the entire failure class.

When should you use Local Clock Only?

You have exactly one device, fully air-gapped, with no certificates, no distributed peers, and no need to correlate its logs against anything — a lab oscilloscope or an offline embedded controller where a battery-backed RTC is the only timekeeper available.

When should you use Time Synchronization?

You run literally anything networked: a server, a phone, a cluster, anything touching TLS, OAuth, Kerberos, databases, or logs you'll one day need to read in order.

What's the main difference between Local Clock Only and Time Synchronization?

Whether to trust a machine's own quartz clock or keep it disciplined against an external time source. One drifts. The other doesn't. This isn't a close call.

How do Local Clock Only and Time Synchronization compare on accuracy over time?

Local Clock Only: Drifts seconds/day (50-100 ppm), unbounded. Time Synchronization: Held to milliseconds (NTP) or sub-microsecond (PTP). Time Synchronization wins here.

Are there alternatives to consider beyond Local Clock Only and Time Synchronization?

Hardware constraints. If you genuinely have no network and no GPS, a temperature-compensated RTC (TCXO) plus periodic manual correction is your fallback — but that's local clock as a hostage situation, not a preference.

The Bottom Line

Time Synchronization wins

An uncorrected quartz oscillator drifts roughly 1 second per day — tens of seconds a month — and every machine drifts in a different direction, so your fleet has no shared notion of "now." The moment you have two computers, a TLS certificate, a JWT expiry, or a log you need to correlate, that disagreement becomes outages and security holes. Time sync (NTP/chrony/PTP) costs nearly nothing and removes the entire failure class.

Related Comparisons