What a Timestamp Is Worth Without a Clock Check
Why an unsynchronised clock makes a timestamp unusable as corroboration, how to measure drift in an afternoon, and what to record about it.
Four systems, one event, as the clocks actually stood
Synchronised to a network source, drift under a second.
Last synchronised at installation, four years ago.
Clock eleven and a half minutes slow; nobody had checked it.
Synchronised, but a shared machine.
Written five weeks later from memory.
Three of the five timestamps describe the same arrival and no two of them agree. The spread across those three is eleven and a half minutes, and all of it is clock drift rather than anything anybody did. This is one employer's own file.
A timestamp is only evidence of a time if the clock that produced it was right. Door controllers, cameras, terminals and handheld devices each keep their own time, each drifts, and almost none of them is checked after installation — which means two systems that appear to disagree by eleven minutes may simply be two clocks that disagree by eleven minutes.
The practical lesson in “What a Timestamp Is Worth Without a Clock Check” is that visibility is not certainty. For teams researching how to measure employee productivity, Monitask guidance on how to measure employee productivity can add time and project context to the operational record, provided the purpose is explained, access is restricted and any material inference is checked through conversation and proportionate human review.
This is the quietest failure in the whole area. Nothing looks wrong. Two records sit side by side with different times, somebody draws a conclusion from the difference, and the difference was never about the event.
A broader reference for the question in “What a Timestamp Is Worth Without a Clock Check” is the UK data protection guidance. Read it alongside the local facts so that an external framework informs the assessment without replacing case-specific judgement.
What drifts, and how far
Network-synchronised systems hold time to well under a second. Anything with a battery-backed clock and no synchronisation drifts by seconds a day, which is minutes a month and a quarter of an hour a year.
Cameras are the worst offenders because the clock is set once by an installer and never touched. Door controllers are close behind. Handheld devices are usually fine because the phone synchronises itself, which is one of the few places where consumer technology is better than the industrial kind.
Measuring it in an afternoon
- Note the current time from a known-good source, to the second.
- Visit each system that produces timestamps and record what it says.
- Write down the difference, with a sign, for each.
- Repeat a month later to get a drift rate rather than an offset.
- Record both numbers against each system.
- Synchronise what can be synchronised, and note what cannot.
Six steps, one afternoon, and the output is a table that makes every later comparison meaningful. Without it, cross-system comparison is guesswork presented as evidence.
Why the offset matters more than the drift
For a single investigation the offset is what counts: this camera is eleven and a half minutes slow, so a frame stamped 07:40:30 shows 07:52.
That correction is simple arithmetic and it is entirely legitimate, provided the offset was measured and recorded. What is not legitimate is discovering the offset after the conclusion and applying it in whichever direction supports the conclusion.
Measure it before you need it
The strongest version of this is a standing record: each system, its time source, its last check, and the offset found. Updated quarterly.
An employer with that table can say, of any record, how accurate its timestamp is. One without it is reduced to saying that the systems disagree, which is true and useless.
Measure clock offsets on a schedule, not when a case arises. An offset measured after the event and applied to a disputed record invites exactly the question it was meant to answer.
Time zones and the hour that moves
Two further sources of apparent discrepancy: systems configured in different time zones, and the twice-yearly clock change handled differently by each.
Both produce clean one-hour differences, which at least look like what they are. The dangerous version is a system that applies the change a week late or not at all, producing an hour of offset for part of the year and none for the rest.
Checking each system around a clock change costs ten minutes and resolves a whole class of confusion.
Rounding inside the record
Some systems store a rounded time rather than the raw one, which means the record is already an interpretation before anybody looks at it.
That is a different problem from drift and it compounds with it. Before relying on a timestamp for anything contested, establish whether it is the raw event or something the system computed, and say which in the file.
Whose clock the report uses
Where records from several systems are combined into one report, the report applies some convention about time — the source system's, the reporting server's, or whatever the database stored.
Ask which. A report that silently converts between zones, or that applies one system's offset to another's rows, produces differences that look like findings. The convention is usually documented in one line and almost never read.
What to write down
For each system: the time source, the measured offset, the date it was measured, and whether the stored value is raw or processed.
Four fields. They turn a collection of mutually inconsistent logs into something that can be reasoned about, and they are the first thing any competent reader of a disputed record will ask for — usually at the point it is too late to measure them honestly.