Free — no signup required

Introduction: Hardware vs. System Time

3 min read

Two Clocks, One Computer

Think of your computer as a hospital patient. When the patient is awake and connected to monitors, the hospital's precise equipment tracks their vitals in real time. But when the patient goes home, a simple wristwatch keeps ticking on their wrist. When they return, the hospital syncs its records with whatever the wristwatch says. Your computer works the same way: a simple battery-powered clock keeps time when the machine is off, and the operating system takes over with higher precision once it boots.

1. The Hardware Clock (RTC)
Deep on your motherboard, powered by a small coin-cell battery (the CMOS battery), lives the Real Time Clock (RTC). It is a dedicated chip whose only job is to count seconds — even when the machine is unplugged, powered off, or in the middle of a firmware update.

  • Job: Persist the current date and time (year, month, day, hour, minute, second) across power cycles.
  • Limitation: It has no concept of time zones, Daylight Saving Time, or leap seconds. It stores a raw counter, almost always in UTC.
  • Precision: Typically accurate to within a few seconds per day — good enough to survive a weekend power outage, not good enough for distributed systems.
  • Tool: hwclock reads and sets the RTC directly, reporting a plain UTC timestamp.

2. The System Clock (Kernel Time)
Once the Linux kernel boots, it reads the RTC exactly once to get a starting timestamp. From that moment on, the kernel maintains its own system clock by counting interrupts from a high-resolution hardware timer (such as the CPU's Time Stamp Counter, TSC, or the HPET chip). This system clock is what every application on your machine actually uses.

  • Job: Provide high-precision time (nanosecond resolution) to running processes via system calls like clock_gettime().
  • Feature: It is adjustable. The kernel can speed it up, slow it down, or step it forward/backward in response to NTP corrections — without touching the RTC.
  • Tool: date for human-readable output; timedatectl status for full status, including local/universal/RTC time side by side, current time zone, and whether the clock is synchronized to NTP.

The Sync Dance
The relationship between these two clocks follows a predictable lifecycle:

  1. Boot: Kernel reads the RTC and initializes the system clock.
  2. Runtime: NTP (or systemd-timesyncd) continuously adjusts the system clock to stay accurate. The RTC is not touched during normal operation.
  3. Shutdown: The kernel writes the current system time back to the RTC so it has an accurate starting point for the next boot.

This means if your machine runs for months without rebooting, the RTC may drift significantly from true time — but the system clock stays accurate because NTP keeps correcting it. The RTC only matters at boot time.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free