Manual Time Setting vs Time Synchronization

Setting a clock by hand versus letting it sync to an authoritative source. One drifts and one self-corrects. There's a winner.

The core problem manual setting can't solve

Every clock drifts. Consumer quartz oscillators wander on the order of one to several seconds a day, worse with temperature swings. Set a machine by hand at 9am and by next week it's tens of seconds off — enough to break Kerberos tickets (default 5-minute skew tolerance), expire TLS certs early or late, scramble TOTP 2FA codes, and make log timelines lie. Manual setting treats time as a value you write once. It is actually a rate you must continuously correct. A human typing the time also injects their own error: reaction lag, a stale wall clock, a wrong timezone assumption. You can't manually re-set every box every hour, which is exactly what staying accurate requires. Manual setting isn't a worse version of sync — it's a different, smaller task (initialize a clock) being asked to do a job (keep a clock right) it structurally cannot do.

What synchronization actually buys you

NTP and its better-behaved daemons (chrony, ntpd) don't just stamp a value — they run a feedback loop. They measure round-trip delay to stratum servers, estimate offset and the local oscillator's drift, then slew the clock gradually so it converges and stays converged. chrony in particular handles laptops that suspend, jittery virtualized clocks, and intermittent links far better than the old ntpd. Over the public internet you realistically hold single-digit milliseconds; on a LAN, sub-millisecond; with PTP and hardware timestamping, sub-microsecond for trading and telecom. Crucially it self-heals: temperature changes, VM migration, a leap second — the loop absorbs them. That's the entire value. Distributed databases, Kafka ordering, Spanner-style commit waits, certificate validity, distributed tracing, and forensic log correlation all assume bounded clock error. Synchronization is the mechanism that produces that bound. Manual setting produces a number and a prayer.

Where manual setting earns its only points

Be fair: there are real cases. A truly air-gapped box with no upstream time source has nothing to sync to — though the right answer there is a local GPS or PTP grandmaster, not a keyboard. Bringing up hardware with a dead RTC battery and no network needs a hand-set starting value before anything else works. Deterministic tests and security drills sometimes demand you pin or fake the clock deliberately. And initial provisioning often hand-sets a rough time so the very first authenticated NTP/NTS handshake (which itself needs an approximately-correct clock to validate certs) can even succeed. Notice the pattern: every legitimate use of manual setting is bootstrap or isolation, never steady state. It's the match you strike to light the furnace, not the furnace. The moment a network appears, sync takes over, and you'd be negligent to leave a connected machine on a hand-set clock.

The trap nobody warns you about: trusting sync blindly

Synchronization wins, but plain NTP is unauthenticated UDP — a man-in-the-middle or malicious upstream can shove your clock forward to expire certs, replay tokens, or backward to bypass expiry checks. This is a documented attack class, not theory. So configure sync like you mean it: prefer NTS (Network Time Security) or symmetric-key auth, pin multiple independent upstreams so one bad server gets outvoted, set sane step/panic thresholds (chrony's makestep, maxchange) so a hostile jump gets rejected rather than applied, and monitor offset as a first-class metric. Don't run a single stratum-1 you don't control as your only source. For sub-microsecond requirements, NTP is the wrong tool entirely — use PTP with hardware timestamping. The verdict stands: sync, always, on anything networked. Just don't mistake 'I installed chrony' for 'my time is trustworthy.' The control loop is only as honest as the source you point it at.

Quick Comparison

Factor	Manual Time Setting	Time Synchronization
Accuracy over time	Drifts seconds to minutes per day; correct only at the instant you set it	Self-correcting loop holds ms on internet, sub-µs with PTP
Works fully offline / air-gapped	Yes — needs no source, just a human and a value	Needs a time source (network, GPS, or PTP grandmaster)
Fitness for distributed systems, TLS, auth	Unfit — skew breaks Kerberos, TOTP, cert validity, log ordering	Designed for it; provides the bounded skew these systems assume
Operational cost at scale	Impossible — can't hand-set every box every hour	Set up once via chrony/NTP, runs unattended across the fleet
Attack surface	None over the wire; error is human and bounded by inattention	Plain NTP is spoofable; needs NTS/auth and step limits to be safe

The Verdict

Use Manual Time Setting if: You are offline with zero trusted time source — a bare-metal box in a vault, an embedded device with no network and no RTC battery — and you accept the clock will drift. Or you are deliberately faking time for a test.

Use Time Synchronization if: Your machine touches a network, issues or validates tokens, writes timestamped logs, talks TLS, or coordinates with any other machine. Which is essentially everything.

Consider: Sync is not free: NTP without authentication is spoofable (use NTS or symmetric keys), and a bad upstream can yank your clock. For sub-microsecond needs reach for PTP, not plain NTP.

The Bottom Line

Time Synchronization wins

Quartz clocks drift seconds to minutes a day, and every distributed system, TLS handshake, log correlation, and auth token assumes machines agree on "now." Manual setting is a snapshot that's wrong by lunchtime. Synchronization (NTP/PTP/chrony) is a control loop that stays right. The only contest is on air-gapped or deliberately offline boxes, and even there you sync to a local GPS or PTP grandmaster.

Related Comparisons