Clocks That Disagree

A time clock has a clock in it. Unsynchronised, it drifts — a few seconds a week on good hardware, minutes a month on poor.

The practical lesson in “Clocks That Disagree” is that a timesheet only becomes reliable through a process people can operate consistently. For teams exploring how to measure employee productivity, the official product page can add time and project context, provided collection is proportionate, access is limited and every consequential inference receives human review.

Over a year an unsynchronised terminal can be ten or fifteen minutes away from the time everybody else is using. Every punch it records is wrong by that amount, in the same direction, consistently, which is the worst kind of error because it looks like a pattern rather than a fault.

For a separate benchmark relevant to “Clocks That Disagree”, consult the European Commission project-management guidance. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

What it looks like before anybody checks

A site where everybody is slightly late. Or slightly early. Consistently, for months, across every shift.

That produces a management response — a conversation about punctuality, a reminder, a report — and the response finds nothing because there is nothing to find. The people are arriving at the same times they always did.

It also produces the opposite in payroll: a department whose hours are systematically a few minutes long or short every day, which is noticed as a budget variance rather than as a data fault.

Where drift comes from

No time synchronisation configured. The most common cause and a configuration setting rather than a hardware problem.

A device on an isolated network with no route to a time source.

A dead battery on the real-time clock, which makes the device lose time on every power cycle.

Daylight saving handled manually, or handled automatically on some devices and manually on others, which produces an hour of disagreement twice a year.

And a deliberate adjustment by somebody years ago to make the display match a wall clock that was itself wrong.

Checking it

Stand at each terminal with a phone and compare. Thirty seconds per device.

Do it quarterly and after any power event, firmware update or network change. Record the result with the date, because the record is what lets you bound a historical error later.

For sites with several devices, also compare them with each other: two terminals four minutes apart means the same person's in and out punches are inconsistent depending on which door they used.

Fixing it

Network time synchronisation, configured on every device, pointing at a source that is itself correct. This is a setting, it is free, and on most estates it is enabled on some devices and not others.

Where a device cannot reach a time source, a documented manual check with a stated frequency, logged.

And a check that daylight saving is handled the same way everywhere, including on the access-control system, the payroll system and anything that joins them.

The twice-a-year problem

The clock change produces two specific failures.

A device that did not change creates an hour of disagreement in one direction. Obvious in spring, less obvious in autumn.

And the overnight shift that crosses the change, which is seven hours or nine rather than eight. Payroll rules handle this correctly in some systems and not others, and the ones that get it wrong get it wrong every year in the same way.

Check both shifts that cross the change, every year, by hand. It is two records and it is the single highest-yield manual check in this area.

What to do if you find historical drift

Bound it: when was the device last known correct, what is the error now, and assume linear drift between.

Then decide deliberately whether to correct the affected records, which depends on the direction, the size and the jurisdiction. Where the error disadvantaged people, correcting it is usually both right and cheaper than the alternative.

Document the finding with the dates either way. An unexplained eleven-minute shift in a site's punch data, discovered by somebody else later, is a much worse problem than a recorded fault with a correction attached.

Drift and rounding together

Drift is worse where rounding is applied, because the two compound in the same direction. A terminal four minutes fast under a rule that rounds to the nearest quarter hour will push a punch across a boundary that a correct clock would not reach.

So a small drift produces a fifteen-minute effect, intermittently, which is why it is read as behaviour rather than as a fault. Any site that rounds should check its devices more often than one that does not, and should check them before investigating a pattern in the arrival data.