What is a timestamp: the term explained for evidence work
A timestamp is a recorded value stating when a particular system observed a particular event, and its evidential weight depends entirely on which clock set it: a device clock the participant controls, a server clock the receiving organisation controls, or an independent third-party clock.
That distinction is the whole subject. Two timestamps can look identical in a case file, sit in the same column of the same report, and support completely different statements once somebody challenges them.
What does a timestamp actually prove?
A timestamp proves one thing. At the moment it was written, the system writing it held the time to be that value, and it attached that value to the event it was recording.
Everything else people ask of it is inference, and whether the inference survives depends on who could influence the clock and who could influence the record afterwards.
- Whose clock it is. A time set by a device the subject controls carries the subject's word. A time set by the receiving system carries the receiving organisation's word. A time set by an independent authority carries a third party's word.
- How tightly it is bound. A time sitting in a separate database column is easier to argue with than a time cryptographically bound to the content it dates.
- What it is dating. A timestamp dates a system event, never a real-world one. The gap between those two is where most overclaiming happens.
Client-side and server-side timestamps are not the same thing
A client-side timestamp comes from the clock on the phone, camera, or computer that produced the file. It is written by software running on hardware the organisation does not control, and changing it takes a settings menu and about fifteen seconds. EXIF capture times, file creation dates, and the clock visible in a screenshot all fall in this category.
Useful as context. Worth very little as proof. Treat a client-side time as a claim made by whoever was holding the device.
A server-side receipt timestamp is written by the receiving system when a submission arrives, from a clock the organisation runs and keeps synchronised. A participant cannot reach it, which is what makes it the workable default for case handling. It also proves something narrower than most people assume: a receipt timestamp proves when the system took delivery of the material, not when the depicted event happened.
A photograph received at 09:14 on a Tuesday may show damage from that morning, from the previous month, or from a vehicle written off two years ago. Receipt time sets an upper bound on the age of the file in that exact form. It sets no lower bound whatsoever.
Timestamp example: the claim received on 3 March
A motor claim arrives with four photographs, receipted at 09:14 on 3 March. In August the insurer has to show the images in the file have not been swapped since. Receipt time, bound to the file fingerprints, supports one defensible statement: this exact content was in the insurer's possession from 09:14 on 3 March onwards.
What it cannot support is that the dent was made on 3 March. If the policy incepted on 1 March, receipt time does not close the pre-existing-damage question. It narrows it, and the rest is assessment work.
How a trusted timestamp works under RFC 3161
The stronger form takes the receiving organisation's clock out of the argument altogether. Under the Time-Stamp Protocol specified in RFC 3161, published in August 2001, the system sends a hash of the data to a Time Stamping Authority, and the authority returns a signed token carrying that hash, its own generation time in UTC, a serial number, and its policy identifier. The data itself never leaves the building.
RFC 3161 states the purpose precisely: the TSA's role is to time-stamp a datum to establish evidence indicating that a datum existed before a particular time. Read the shape of that claim carefully. It is existence before a moment, not occurrence at a moment. Even the strongest timestamping standard in common use is careful not to say more.
Inside the EU, Article 41 of Regulation (EU) No 910/2014 (eIDAS) adds a procedural advantage for a qualified electronic time stamp, which enjoys the presumption of the accuracy of the date and time it indicates and the integrity of the data those are bound to. The practical effect is on burden of proof. The party disputing the time has to displace the presumption, rather than the party relying on it having to build it from scratch.
Where timestamps get overread
- Receipt time treated as incident time. The most common error by a wide margin, and the first thing a well-prepared opponent will take apart.
- Metadata quoted as authority. EXIF times get lifted into case notes and repeated as if a third party had set them. They are device statements.
- Missing offsets. A time recorded without an explicit UTC offset invites an argument about whether it is local or universal. Record UTC, display local.
- Clock drift. An unsynchronised server clock undermines its own records. Time synchronisation belongs in the evidence story, not only in the infrastructure runbook.
Time is one layer among several, and on its own it is thin. Paired with a hash it dates a specific content, paired with a cryptographic signature it becomes attributable, and inside an audit trail it becomes a sequence rather than a point. The entries on evidence integrity and chain of custody cover how those layers fit together around a case.
Venta Capture, a product of VentaVid, records a server-side receipt time on every submission and binds it to SHA-256 file fingerprints and a recorded session timeline. The claim it supports is the narrow one stated above: when the system took delivery, and that the content has not changed since.