Consent timestamps and clock skew: when your proof of consent argues with itself

A typical consent stack touches three clocks. The banner script reads the visitor's device time. Your server logs its own time when the consent endpoint is called. The consent platform timestamps the record on its infrastructure, in its configured timezone. Nobody notices while all three roughly agree. Then a visitor with a device set to the wrong year, or a platform configured to a head office timezone twelve hours away, produces a record whose sequence is impossible, and the impossibility is what an auditor or a complainant's screenshot preserves.

Timezones do the quieter damage. A timestamp stored without its zone is a string, not a moment. Consent given at 23:30 in California appears, read as UTC, to precede a page view it followed. Multiply by every record in the register and your retention calculations, which delete or renew consent on age, start firing on the wrong records.

How the disagreement gets in

Pick the consent platform or your server as the single timestamp authority and let the other systems store that value rather than minting their own. Store it in UTC in the record, alongside the visitor's timezone identifier as its own field, the consent version, and the categories granted. Those five fields together let you reconstruct any consent event exactly, in either clock, without inference.

Run a skew check quarterly: sample recent records, compare the platform timestamp with your server log for the same event, and investigate any gap beyond a few seconds. Skew creeps in through configuration changes and vendor migrations, and the quarterly check is cheap insurance against discovering it during a complaint.

The recording standard that survives audits

Consent expiry and renewal prompts are computed from these timestamps, so a skew is not only an evidence problem. Records stored hours or days off age out early or linger past their policy life. A register that cannot prove when consent was given also cannot prove it was still valid when the marketing email was sent, which is usually the question actually being asked.

Retention runs on timestamps, so get them right

Keep reading: Cookiebot Alternatives: A Practical Comparison, Consent on Checkout Pages: What a Banner Must Never Block.

Frequently asked questions

Why do consent records from different systems disagree on time?

Because each system stamps the event with its own clock and timezone: the visitor's device, your server, and the consent platform. Device clocks can be wrong by hours and platforms are often configured to a head office timezone. Mixing the three sources produces records whose sequence looks impossible.

How should consent timestamps be stored?

From one authoritative source, stored in UTC, with the visitor's timezone recorded as a separate field, plus the consent text version and categories granted. That combination lets any event be reconstructed exactly, in either local or universal time, without guesswork.

Does a small time difference in a consent record really matter?

Minutes rarely do. Hours and missing timezones do, because auditors test sequence: consent must precede the processing it authorises. A record showing collection before consent, even as a clock artefact, undermines the register's credibility as evidence.

How often should timestamp consistency be checked?

Quarterly is a sensible cadence, sampling records and comparing platform and server timestamps for the same events. Skew usually enters through configuration changes or vendor migrations, and a routine check finds it before a complaint does.