data.day
case study / forensics / esignatures

The Contract Signed Twice Because Two Clocks Disagreed

A case study in forensic failure. How a mismatch between 'Wall Clock' time and 'System Time' nearly invalidated a digital signature.

Lars Parse Lars Parse

The Witness That Lied

In a physical signing, we look at the clock on the wall. We write the time. The ink dries. It is done.

In a digital signing, there are two clocks.

  1. The Wall Clock: The time on the user’s laptop (e.g., the Client).
  2. The System Clock: The time on the cloud server (e.g., the Vault).

These two clocks rarely agree.

In the case I reviewed, a contract option expired at 5:00 PM. The client signed at 4:55 PM, according to their laptop. They felt safe. However, their laptop was configured to a different timezone than the server expected. The PDF generator took the user’s local time string (“16:55”) but did not stamp the timezone offset.

The server received the packet. The server runs on UTC. The server recorded the event at 22:55 UTC.

When the dispute arose, the auditors compared the visual PDF stamp (16:55) with the server log (22:55). They applied the expected offset. The math did not add up. There was a discrepancy of one hour.

The False Security: Relying on User Devices.

The vulnerability here was trusting the endpoint. The Machine on the user’s desk is unreliable. Users change their clocks to cheat in video games. Users have dead CMOS batteries. Users travel without updating their settings.

If your evidence relies on the user’s clock, your evidence is weak.

The visual stamp on the PDF—“Signed at 4:55 PM”—gave the client a false sense of security. They believed the timestamp was a verified fact. Strictly speaking, it was just user-submitted text, no different than a comment.

The Mathematical Reality: The Canonical Timestamp.

To survive a legal challenge, we must architecture our records to hold two distinct values.

  1. Evidence Time (UTC): This is recorded by our server, which is synced via NTP (Network Time Protocol) to an atomic clock. This is the truth. We trust this.
  2. Context Time (Local): This is the offset the user claimed to be in. We record this only to reconstruct their user experience later.

In the case study, if the system had properly recorded that the user was in UTC-5 but the server was in UTC, the one-hour discrepancy would have been explained by a Daylight Savings boundary issue. Instead, the lack of data looked like fraud.

We fixed the system. We removed the user’s ability to influence the legal timestamp. The server now stamps the PDF based on its own internal, atomic reality.

If you are responsible for digital agreements, ask your vendor: “Whose clock applies the stamp?” If they say “The user’s,” you are paying for a liability.

FAQs

Which time is the 'real' time?

UTC is the real time. It is the heartbeat of the planet. Local time is just a costume we wear for comfort.

Can I just sync my laptop clock?

It helps, but you cannot force your clients to sync theirs. You must design the system to handle their inaccuracy.

What is NTP?

Network Time Protocol. It keeps servers synchronized. If your NTP daemon fails, your evidence becomes inadmissible.