The Off-Key Bard
Technology

How Does Your Computer Know What Time It Is, Even When It's Turned Off?

Or: why a tiny battery, a quartz crystal, and an internet connection keep the digital world on schedule. Your computer doesn't know what time means. It just counts reliably and occasionally asks a better clock.

Or: Why a Tiny Battery, a Quartz Crystal, and an Internet Connection Keep the Digital World on Schedule

Turn off your computer tonight, unplug it from the wall, and leave it that way until morning. When you plug it back in and start Windows, the clock will probably be right before you've opened a browser. That's odd when you think about it. All night the processor wasn't executing instructions, the operating system wasn't running, and the power supply wasn't feeding the motherboard. Yet something kept counting seconds.

Now picture the opposite: an older machine whose clock says January 1, 2000 and resets itself after an overnight unplug, while secure websites refuse to load. These problems share a root, the computer's clock.

Keeping time takes cooperation: a small hardware clock runs while the machine is off, firmware reads it at startup, the operating system takes over, and a network connection lets the computer check itself against better references.

A Computer Has More Than One Clock

When we say "the clock," we usually mean the numbers beside the taskbar. Inside, several timing systems do different jobs. The CPU uses clock signals to coordinate its internal operations. Hardware timers help the operating system measure intervals and schedule tasks. A separate real-time clock, or RTC, maintains calendar time: hours, minutes, seconds, and dates.

A processor running at several gigahertz doesn't use that signal as a wall clock; its clocking exists to coordinate computation. The operating system's running clock also differs from the battery-backed hardware one, which supplies an initial reference at startup.

The Real-Time Clock and Its Coin Cell

Most desktop motherboards include an RTC, though it may be built into a chipset or system controller instead of sitting there as one obvious part. It's a low-power function whose only job is to keep a sufficiently accurate count of elapsed time in a form the system can use. Because it draws so little, it can run from a small backup battery when the computer has no other power.

That battery is the silver coin on the board, usually a CR2032, a three-volt lithium cell. People call it the CMOS battery, a leftover from older designs where battery-backed CMOS memory preserved BIOS settings alongside the clock. Modern UEFI systems often keep their configuration in flash that needs no battery, but the coin cell still commonly backs the RTC. So a dead battery doesn't necessarily erase every firmware setting on a modern board, and the most recognizable symptom is a clock that loses the correct time after the machine has been fully disconnected.

Such a small cell can last years because the demand is tiny. Analog Devices' design note on crystals for RTCs says a small lithium battery can power the oscillator and clock circuitry while the main supply is off, and that to maximize battery life the oscillator "must run using as little power as possible," with drive levels kept under a microwatt. Lifespan varies with board design and temperature, but several years is common. When the voltage finally sags too low for the backup circuitry, the clock stops being reliable while the rest of the hardware stays healthy. A failing clock battery isn't a failing computer.

How a Crystal Counts Seconds

The RTC needs a repeatable physical process to count against, and the usual choice is a quartz crystal. Quartz is piezoelectric: an electric field deforms it slightly, and mechanical stress produces an electrical response. Pair a crystal with suitable oscillator circuitry and it sustains a stable, repeating vibration that acts as a frequency reference.

Many RTCs use a crystal at 32,768 hertz. The number looks peculiar until you notice that 32,768 is 2 to the fifteenth power. Digital circuitry can halve the frequency fifteen times to land on exactly one cycle per second, a convenient basis for counting. (Analog Devices' note specifies this frequency and calls the parts tuning-fork crystals, but doesn't explain the choice; the powers-of-two logic is the standard explanation.)

The RTC doesn't understand Tuesday. An oscillator makes cycles, digital counters tally them, and firmware and the operating system apply the rules that turn the count into a date and local time. The computer doesn't experience time. It counts a regular sequence of electrical events.

Crystals Aren't Perfect

A quartz oscillator is stable but not exact. Manufacturing tolerance, temperature, aging, and circuit details nudge its frequency slightly off target, and a clock built on a fast oscillator accumulates extra seconds while a slow one loses them. That's clock drift, usually quoted in parts per million.

Take a clock running 20 ppm fast. A day has 86,400 seconds, so 20 parts per million comes to about 1.7 seconds a day: roughly twelve seconds over a week and nearly 52 seconds over thirty days. Analog Devices' note lists a typical crystal tolerance of plus or minus 20 ppm and puts it plainly: "An error of 20ppm is equivalent to approximately 1 minute per month." Not every RTC is that far off, since real accuracy varies with design and conditions, but it shows why a local oscillator alone isn't enough when timestamps need to line up.

Temperature matters too. The same note says crystals drift from their base frequency as temperature changes, with a turnover point near 25 degrees Celsius, and the further the operating temperature is from it, the slower the crystal oscillates. Better accuracy is available from temperature-compensated oscillators, but ordinary desktop RTCs are designed around cost, low power, and adequate accuracy. That's reasonable, because the operating system can fix the time over a network. The hardware clock's job is to keep a useful approximation while the machine is off.

What Happens at Startup

When you press the power button, the sequence from yesterday's article unfolds, and along the way the firmware can read the RTC for an initial calendar time before the operating system builds its own timekeeping structures. Once Windows is running it doesn't keep asking the coin-cell clock what time it is. The battery-backed RTC gives continuity across shutdowns; the running OS handles ongoing time and corrects it from outside references.

The OS can't just count instructions, since processors change frequency dynamically, so it relies on dedicated timing facilities. And it distinguishes wall-clock time, which answers "what's the date?" and can be adjusted, from monotonic time, which measures elapsed intervals and never jumps backward when someone corrects the date. A timer shouldn't misbehave because the calendar moved back an hour.

Asking a Better Clock

To limit drift, operating systems synchronize with outside sources, most commonly through the Network Time Protocol, or NTP. Defined in the Internet Engineering Task Force's RFC 5905, NTP organizes time sources into a hierarchy called strata. Stratum 0 refers to reference clocks such as atomic clocks and GNSS receivers, while stratum 1 servers synchronize directly with those references. Higher-numbered strata represent additional steps away from the original reference, not necessarily lower accuracy. A stratum 3 server can sometimes provide more accurate time than a stratum 2 server because network conditions, oscillator quality, and server configuration all influence the result.

The internet doesn't deliver time instantly, so simply copying a server's timestamp would bake in the transit delay. NTP exchanges timestamps for when the request and response were sent and received and uses them to estimate the offset between the two clocks. That estimate assumes the outbound and return paths take roughly equal time. Wikipedia notes that when they don't, a systematic bias of half the difference appears, that NTP can usually keep time within tens of milliseconds over the public internet, and that asymmetric routes and congestion can cause errors of 100 milliseconds or more.

On Windows the work falls to the Windows Time service, W32Time. Microsoft's documentation says it uses NTP to synchronize clocks and, though not an exact implementation of the protocol, uses the algorithm suite defined in its specifications. Domain-joined computers generally follow the domain hierarchy rather than an arbitrary internet source, and under reasonable conditions Microsoft says systems can maintain 1 millisecond accuracy or better against UTC. A home PC usually syncs with a configured internet source. This isn't a one-time lookup. Good synchronization has to manage drift, delay, and changing conditions.

Clock synchronization also needs to avoid unnecessary jumps. NTP's clock-discipline algorithms can correct smaller errors by adjusting the effective rate of the local clock, allowing it to converge gradually toward the reference time. Larger discrepancies may require an immediate correction. The exact behavior depends on the operating system and its time-synchronization configuration, but the objective is the same: maintain accurate time without disrupting applications that rely on consistent timestamps.

Time Zones, UTC, and Daylight Saving

Servers, databases, and applications in different countries need to agree on when something happened, so systems commonly keep time in Coordinated Universal Time, UTC, a standard scale tied to no time zone. A computer keeps timestamps relative to UTC and converts them for display. Fly from South Carolina to California and your phone's shown time shifts by three hours, but the underlying UTC value is unaltered; only the display offset moved.

Daylight saving is likewise a software rule. Neither a crystal nor an RTC knows when it starts. Time-zone data says which regions change clocks and when, so the display can jump from 1:59 a.m. to 3:00 a.m. while elapsed time stays continuous. Governments sometimes change the rules, which is why that data needs updates.

This gives you a diagnostic. A clock off by exactly an hour, or by several hours, usually points to time-zone or daylight-saving configuration, not the battery, because drift accumulates gradually while zone errors produce fixed offsets. Losing minutes over a week suggests a different layer than showing the right minutes with the wrong hour.

Dual-boot machines add a classic trap. Windows has traditionally treated the hardware RTC as local time, while many Linux installations keep it in UTC, so the displayed time can shift by hours. The hardware clock wasn't inaccurate; the operating systems disagreed on what its numbers meant.

When a Wrong Clock Breaks Things

The strangest consequence shows up in security. Suppose your computer thinks it's 2018 and you open a legitimate HTTPS site. The browser warns you. Why should the date matter? Because HTTPS relies on digital certificates, and certificates carry a validity window. RFC 5280, the standard for X.509 certificates, defines the validity period as running from notBefore through notAfter, inclusive. If your computer believes the current time is outside that window, it may reject a perfectly good certificate: one issued in 2026 looks not yet valid to a PC set to 2020, and one that's current looks expired to a PC set to 2035. The browser isn't necessarily saying the site was compromised. It can't establish trust because your clock is wrong.

That's why an older PC unplugged for a long time can show certificate warnings on nearly every secure site even though the network works. Check the date first, but don't click through certificate warnings on the theory that the clock is probably to blame. Fix the time and confirm the connection works normally.

Authentication leans on time too. Microsoft's documentation calls the Windows Time service essential to Kerberos V5 authentication, used in Active Directory, so when a client and server disagree too much, login can fail even with the right password. Authenticator apps are similar: their six-digit codes change every thirty seconds and derive from a shared secret and the current time interval (the standard is TOTP), so a device clock that is too far off produces codes the server rejects.

Everyday data depends on the clock too. File timestamps tell users and backup tools when something changed, so a wrong clock can make a document look years old and confuse sorting and sync, and logs from machines that disagree on the time make a misleading timeline. The contents aren't corrupted, but the metadata about their history is.

When Precision Matters More

An ordinary home PC doesn't need microsecond accuracy, but financial trading, telecommunications, and scientific instruments can, using GPS timing and the Precision Time Protocol on suitably designed networks. A coin-cell RTC could never be their only reference. Large distributed systems face a harder version, since their machines share no perfect clock, so they use logical clocks and sequence numbers to order events.

Offline, Dead Battery, and Quick Checks

If the internet goes away, your computer doesn't forget the time. The OS keeps advancing its clock from local timing and corrects itself when synchronization returns, which is plenty for everyday use.

A dead RTC battery behaves differently. On a typical desktop the clock may lose the time whenever the machine is fully disconnected. The catch is that a computer left plugged in may keep supplying standby power to the RTC and look fine, so the date goes wrong only after an overnight unplug. That pattern is a strong hint to check the battery. Many desktop boards take a replaceable CR2032, but laptops and compact systems may use other arrangements, so follow the maker's instructions. The aim is to restore backup power, not to paper over the problem by editing the date in Windows.

A good battery doesn't guarantee a right clock. Other causes include the wrong time zone, automatic sync turned off, a failed network time request, dual-boot conventions, or a bad manual setting. A reset that happens only after unplugging points at the battery, a consistent offset of hours points at zones, and slowly gaining or losing seconds suggests drift or failed sync.

In Windows 11, Settings, Time & language, Date & time shows whether automatic time is on, which zone is selected, and lets you sync. For more detail, w32tm /query /status shows the Windows Time service's synchronization state and w32tm /query /source shows its current time source. For most home users, checking the zone and automatic sync is the best first step.

The Bard's Take

A computer doesn't know the time because someone typed the correct date into Windows. It knows because several systems cooperate to measure and maintain the passage of time. While the machine is off, a tiny real-time clock runs on a backup battery, its quartz crystal supplies a reference, and electronic counters tally the cycles. At startup, firmware reads that clock to establish an initial time and the operating system takes over with its own timekeeping. Since local oscillators aren't perfect, Windows compares itself with network sources through the Windows Time service and NTP, nudging small errors and correcting large ones. Time-zone rules then decide how that shared time appears on your screen.

It matters far beyond knowing when lunch is. HTTPS certificates have validity periods, authentication systems use timestamps, one-time codes change every thirty seconds, file metadata records when things changed, and logs reconstruct events across machines. A computer with the wrong date can have perfectly healthy hardware and a working network and still refuse to open secure websites or log in. The clock isn't a convenience. It's part of the computer's security and coordination infrastructure.

And it all starts with something simple. A tiny crystal vibrates. A circuit counts the vibrations. A small battery keeps the circuit alive. The operating system compares its count with more accurate references. And the digital world agrees, closely enough, on what time it is. Your computer doesn't need to know what time means. It only needs to count reliably, and occasionally ask a better clock whether it's still right.

Sources

← Back to the Desk — Technology