Fixing “Time Drift”: Why Is My Time Clock Always Wrong?

This guide explains why time clocks drift and how to give your business one reliable source of time so payroll stays fair and disputes go away.

Your time clock is almost certainly not “broken.” It is slowly drifting because its internal timekeeper runs a little fast or a little slow, and tiny errors pile up into minutes. The real fix is to stop treating every device as its own clock and instead give your business one clear source of truth for time, then tie everything else back to it.

Picture this: employees swear they clocked in at 8:00 AM, your time clock says 7:56 AM, the wall clock says 8:03 AM, and their cell phone shows something else again. Tension rises, even though most off-the-shelf clocks are designed to be off by roughly a second a day, which adds up to several minutes a year and makes these arguments almost inevitable. The good news is that you can tighten this up without buying a lab-grade atomic clock. You just need to understand what causes drift, decide what “accurate enough” means for your shop, and put a simple, repeatable fix in place.

What “time drift” really means in your business

Clock drift is the slow gain or loss of time that happens when a clock’s internal oscillator runs slightly fast or slightly slow compared with a reference. Every real-world clock will wander unless you periodically pull it back to a standard such as Coordinated Universal Time (UTC) or an atomic time scale. Clock drift comes from tiny imperfections in the hardware and the environment: temperature swings, power fluctuations, component tolerances, and aging all nudge the frequency off its ideal value a few parts per million at a time.

Most modern time clocks and wall clocks use a quartz crystal that vibrates at a steady rate. That vibration is counted to measure seconds, minutes, and hours, and the same principle runs in your phone and computer. Quartz is far better than old pendulum clocks, which can lose around 15 seconds per day. Phones and similar oscillators typically hover around a second a day under normal conditions thanks to their much higher oscillation rate and more stable design, yet they still drift enough that they must be regularly corrected against atomic references. Cesium-based atomic clocks define the modern second so precisely that top designs would lose about one second in billions of years, which is why global time services are built on atomic hardware rather than quartz.

Engineers describe drift in “parts per million” (ppm), meaning how many microseconds a clock gains or loses each second compared with an ideal source. In telecom and networking systems, a frequency error of only a few ppm is enough to accumulate measurable time error, so standards bodies set tight limits on acceptable frequency offset and define how much drift a clock may generate or tolerate over time. A reference example is a clock running 4.6 ppm fast: it will gain 4.6 microseconds each second and grow to a 46-microsecond offset after 10 seconds, illustrating how micro-level frequency error becomes macro-level time error as seconds accumulate into days and weeks. Clock design texts use these kinds of calculations to specify how often clocks must resynchronize to stay within required bounds.

For everyday business devices, those ppm numbers translate into practical ranges. A deviation around 10–12 ppm corresponds to drifting about one second per day, which is considered normal behavior for common 32.768 kHz watch crystals and their supporting circuits and aligns with what hardware tinkerers measure when they track retail digital clocks over months. In other words, your time clock being off a few seconds today is not a failure; it is the expected result of its inexpensive timebase doing its best without help.

The hidden oscillator inside your time clock

Inside a typical punch clock or digital wall clock is a tiny quartz tuning-fork crystal, often running at 32.768 kHz, plus a bit of circuitry that turns its vibrations into a square wave that electronics can count. That oscillator is specified with some tolerance, and its effective frequency depends not only on the crystal itself but also on the capacitors and layout around it. Swapping in a theoretically better crystal rarely cures drift by itself. When an engineer tried to fix a bedside clock that gained about one second per day by installing a higher-grade crystal, the drift barely changed; only after carefully tweaking the surrounding capacitance in 1-picofarad steps did the clock settle down to losing roughly a second every couple of weeks and far fewer seconds per year.

This matters for operations because it tells you two things. First, two clocks with the same part number can drift differently simply because their crystals and surrounding components land on different edges of their tolerances, so one time clock might run consistently fast while another in the same batch runs slightly slow. Second, unless your device was built with a way to “trim” its oscillator or apply software correction, the practical path is not to repair the timing circuit but to resynchronize it regularly or upgrade to a model that can follow an external reference.

Why your time clock disagrees with everything else

When employees compare a physical time clock against their phones or PCs, they are really comparing several independent clocks that are all drifting in slightly different directions and at slightly different speeds. Even a 50 ppm mismatch between two devices—on the order of what you can see between independent audio converters—creates a rate difference of just a few samples or microseconds per second, yet those tiny divergences add up quickly and can distort timing-sensitive measurements if left uncorrected. Audio measurement tools that drive speakers from one clock and record microphones with another routinely see their recordings go out of alignment over just a few seconds of test tone, which is why they use clock drift correction to compute the sample-rate mismatch and stretch recordings back into sync. Clock drift correction techniques are a direct demonstration that even small ppm differences create big headaches over time.

In a building with wireless wall clocks tied to a master controller, you add another layer in the chain: the controller’s own time source plus the radio link that keeps all the child clocks synchronized. A facility system such as a SiteSync wireless clock network uses a central controller that locks its time via Ethernet or GPS, then broadcasts that time to every clock so they all tick together. When everything is healthy, every clock face in the hallway should match the controller exactly. Manufacturer guidance emphasizes that if one or two clocks are out of sync while others are correct, the local problem is usually a missed wireless signal, a weak or damaged antenna connection, or a battery issue rather than a global time error. Diagnostics such as an “ETH=S” or “GPS” status on the controller, color-coded receiver LEDs on the clocks, and visual indicators like solid versus flashing colons on digital displays all exist specifically to help you identify where the chain has broken between the master clock and the out-of-step devices. Wireless clock system checks are designed to be run a couple of times a year, especially at daylight saving time changes, to keep the entire herd of clocks together.

On PC-based or cloud time clock systems, the story shifts from quartz error to network discipline. The operating system maintains its own hardware clock, then uses the Network Time Protocol (NTP) to periodically compare that clock to remote time servers and adjust as needed, usually by gently slewing the clock to avoid sudden jumps. In well-tuned environments with stable network delay, administrators report that NTP holds servers within a few milliseconds of their references, which is plenty accurate for time and attendance. Jittery or congested connections, however, can push offsets into the hundreds of milliseconds unless network congestion control is addressed. The experience of operators who changed their network stack to prioritize stable delay rather than sheer throughput shows offsets dropping from more than a tenth of a second to just a few milliseconds once time-sensitive traffic is protected and link saturation behavior is improved. Practical NTP tuning discussions underline that the network’s health is part of your timekeeping system.

Virtual machines add yet another wrinkle. When your time-clock application runs inside a VM, the guest’s sense of time depends on both its own clock and the hypervisor’s scheduling. High CPU overcommitment, long pauses, snapshots, and live migrations can all cause the guest clock to fall behind or jump ahead. Platform vendors document cases where VMs running NTP in “slew-only” mode remained several seconds or even minutes wrong for days after a migration because the software was deliberately limited to correcting time at a slow rate to avoid abrupt steps. Guidance for VM timekeeping and vendor best practices converge on a simple rule: pick one authoritative time-sync mechanism and let it correct aggressively when offsets are large, instead of running several partial or conflicting methods that never fully catch up.

When is time drift a nuisance versus a payroll risk?

From a pure hardware perspective, a PC or digital time clock drifting about one second per day—roughly 30 seconds per month or around 6 minutes per year—is normal, not a defect. That matches both what watch-grade quartz hardware is rated for and what engineers see when they measure consumer clocks over long periods. It is essentially the cost of using inexpensive oscillators instead of atomic references. In a workplace that regularly pulls device time from an internet time source or a synchronized master clock, this level of drift never fully accumulates because clocks are quietly nudged back into line before anyone notices.

The risk shows up when a device is allowed to free-run for months or years with no correction, or when different pieces of your timekeeping chain disagree in ways employees can see and argue about. Imagine a stand-alone punch clock that has run 3 minutes slow for a year, a wall clock in the break room that is 1 minute fast, and employees checking their phones, which are tightly synced to atomic time over the internet. An employee who walks in right on the dot according to their phone but still gets marked late will feel cheated, even if the drift is technically within the manufacturer’s spec. Multiply that by twenty or fifty people and you create a steady drip of morale issues and disputes every pay period.

The other blind spot is aggregate error. Suppose your time clock runs consistently 2 minutes fast and you do not round punches. A worker scheduled for 8:00 AM who arrives at 8:01 AM by true time might be recorded at 8:03 AM every day. Over a 5-day week, that is 10 minutes of apparent lateness, and over a year it becomes hours of “lost” time that show up in attendance reports, performance reviews, or disciplinary records. Even if pay is rounded generously and nobody loses money, the data picture of who is “reliable” becomes skewed by a clock that simply runs hot.

A practical plan to fix time drift in your shop

The first decision is to pick a master time source that everything else in your business will follow. For most small operations with reliable internet, this should be an NTP-backed source such as your server, firewall, or a dedicated network time appliance that itself syncs to public atomic time services maintained by standards labs. Foundational NTP documents explain how clients continually compare their clocks to upstream servers and adjust, but you do not need to wade into the math. What matters is that every time-aware device in your environment is pointed at one consistent, trustworthy reference.

If you run a wireless facility clock system, treat the system controller as that master and make sure it is healthy. Confirm that its display says it is successfully syncing via Ethernet or GPS, not stuck in a “no sync” state. If it reports Ethernet failure, double-check network connectivity and, if needed, have IT confirm that the controller can reach the internet. For GPS-based units, ensure the antenna has a clear view of the sky and that its cable is firmly attached to the controller. Then walk the building and watch the clocks themselves: analog and battery-powered units often have a diagnostic LED that blinks green when they receive time updates and red when they do not, while newer digital clocks may tell you whether they made their last hourly check-in or have missed several. Using the manufacturer’s recommended once- or twice-a-year inspection around daylight saving time gives you a simple rhythm: fix antennas, replace weak batteries, and retire any clocks that consistently fail to join the flock. Maintenance recommendations for wireless clocks are intentionally modest so regular staff can carry them out.

For PC-based time clocks and on-premises time-and-attendance software, verify that both the host and any dependent workstations are configured to use NTP and that they refer to more than one upstream server for robustness. On servers and routers, this typically means defining three or four NTP servers, enabling options that allow the clock to “step” when the offset is large, and avoiding configurations that only permit slow slewing of big errors. Real-world cases where clocks were allowed to chase multi-second offsets only by slewing demonstrate that, at the Linux kernel’s maximum correction rate of about 500 ppm, even a 10-second error can take hours to erase. Offsets of several minutes can linger for days if you refuse to let the clock jump. Operational NTP case studies and VM-focused guidance from major vendors converge on the same lesson: if a clock is badly wrong, step it back into place quickly, then use slewing for fine-tuning.

In virtualized environments, tighten the chain further. Ensure your hypervisor hosts are themselves synced to solid NTP sources, then choose whether guest VMs should track time directly from NTP or from the host via the virtualization tools layer, but not both at once. Vendor documentation and incident reports highlight that running multiple overlapping time-sync mechanisms can cause instability, as one process slews the clock gently while another periodically yanks it, leading to oscillations and persistent offsets. After disruptive operations like long suspends, snapshot restores, or live migrations, it is wise to trigger an immediate resync for any VM that runs payroll, timeclock, or authentication services so it does not quietly drift for hours before its next scheduled correction. Engineering discussions of synchronization chains reinforce that time hierarchy should be simple and well defined.

If you operate in a secure or offline setting where internet time is not an option, you can still tame drift with a bit of patience. One approach used in hardware security modules is to treat an external trusted clock—such as a workstation that does have access to good time—as your temporary reference, then let the offline device run undisturbed for several days while you log how far it drifts. After at least three days, you compare its displayed time against the reference, compute the average error in seconds per day, and configure a manual drift rate that the appliance uses to compensate going forward. Following this measure–configure–verify cycle over multiple three-day windows allows you to hone in on a correction that keeps the isolated device close enough to true time for its purpose, even without continuous NTP connectivity.

Finally, build a light-touch routine into your operations so time never becomes a surprise again. Choose one or two calendar points—many teams use the start and end of daylight saving time—and dedicate a short check to time devices. Compare the main time clock, a reference PC, and a phone in your local time zone, and if anything is more than, say, 30–60 seconds off, investigate why. Over time you will learn which models hold time well and which ones need more frequent attention or replacement, and you can make upgrade decisions based on their real-world behavior rather than brochure claims.

Choosing the right timekeeping approach

The right fix depends on how central accurate time is to your operation, how sensitive your workforce is to perceived fairness, and how much infrastructure you already have. The following table frames common options in plain terms.

The sweet spot for most operations-focused leaders is a networked approach: either a building clock system anchored by a GPS or Ethernet master, or a PC/VM-based time clock tied to disciplined NTP. These options give you a single time spine through the business, remove arguments about which clock to believe, and make it easy to demonstrate that your records were based on an industry-standard time source anchored in atomic clocks and global standards.

Bringing your clocks under control

Time drift is not a moral failing of your team or a mysterious curse on your time clock; it is a predictable side effect of cheap oscillators doing their best in the real world. Once you treat time as an operational system—pick a master, wire or configure everything to follow it, and give that system a quick health check a couple of times a year—you eliminate most of the daily friction and noise around “what time was it really.” Put a clear time strategy in place now, and the next time someone asks whether the clock is wrong, you will have both the data and the confidence to answer in seconds instead of arguments.

About the author

Silas Mercer

Small Business Efficiency StrategistWorkforce Management ConsultantCloud Systems Integration Specialist

Silas Mercer doesn't just track time; he reclaims it. With over 15 years of experience turning chaotic back-offices into well-oiled machines, Silas creates content for business owners tired of payroll errors and time theft.

As a pragmatic 'Operations Fixer,' he specializes in bridging the gap between complex cloud technology and everyday small business needs. His mission? To help you implement NGTECO’s AWS-secured solutions to automate attendance, ensure compliance, and focus on what really matters: growth. No jargon, just results.