The Clock Is Infrastructure

Every log line, every database transaction, every TLS certificate check, every distributed consensus decision depends on a shared notion of time. When clocks drift, systems fail in confusing ways: logs appear out of order, certificates seem valid or invalid unexpectedly, and distributed databases cannot determine which write happened first. Time synchronization is quiet, essential infrastructure.

NTP: Network Time Protocol

NTP synchronizes clocks across a network using a hierarchy of strata:

  • Stratum 0: reference clocks (atomic clocks, GPS receivers) that are not on the network.
  • Stratum 1: servers directly attached to a stratum-0 clock.
  • Stratum 2: servers syncing from stratum 1, and so on.

NTP measures the round-trip delay to a server and estimates the offset, then gradually adjusts the local clock—slewing it rather than jumping, so time never runs backwards during normal operation. A well-synced host stays within milliseconds of true time; NTP can achieve sub-millisecond accuracy on a LAN.

Clients and Best Practices

The classic ntpd is increasingly replaced by chrony (Linux) and native clients (Windows Time, macOS). Best practices:

  • Configure multiple upstream servers for redundancy and to detect a lying source.
  • Prefer nearby, well-connected servers to reduce network jitter.
  • Monitor synchronization status (chronyc tracking, ntpq -p) and alert when a host loses sync.
  • Use authentication (NTS) where available, so a network attacker cannot spoof time.

When You Need More Precision: PTP

PTP (Precision Time Protocol, IEEE 1588) achieves sub-microsecond accuracy using hardware timestamping—the network interface records the exact moment a packet arrives, avoiding OS and software jitter. PTP is used in financial trading, industrial control, telecom, and anywhere that needs precise, coordinated timing. It requires PTP-capable hardware and careful network design, which is why NTP remains the default for general systems.

Why Drift Is Dangerous

  • Certificates: a clock far enough off can make valid certificates appear expired or not-yet-valid, breaking TLS.
  • Distributed systems: consensus algorithms (Raft, Paxos) and databases like Spanner rely on bounded clock skew to order events.
  • Log correlation: security investigations depend on consistent timestamps across hosts; a drifting server can hide or misorder evidence.
  • Authentication: TOTP codes, JWT expiry, and signed requests with timestamps all fail if clocks disagree.
  • Scheduling: cron jobs, rate limiters, and leases misbehave when time jumps.

Lost Sync Is a Security Event

An attacker who can spoof NTP responses can manipulate system clocks to invalidate certificates, replay or expire tokens, and disrupt logging. This makes time synchronization part of the security perimeter: use authenticated time sources, monitor for large time steps, and treat sudden clock changes as a potential indicator of compromise.

Time Zones and UTC

None of this is about local time zones. Systems should store and compare timestamps in UTC and convert to local time only for display. Time zone conversions are a frequent source of bugs in data pipelines and logs—always keep the canonical record in UTC, and include the offset or zone explicitly in any human-facing timestamp.

Reliable time is unglamorous and nearly invisible—until it breaks, at which point it can take down authentication, consensus, and observability simultaneously. Treat it as first-class infrastructure, not an afterthought.