Time Is Evidence. Not Decoration.

The Broken Clock in the Courtroom

Time is the primary axis of any investigation.

• “Did they approve the wire transfer before or after the sanctions list was updated?”
• “Did the employee download the file before or after they were fired?”

If the answer is “It depends on which clock you look at,” you have lost the argument.

Most software developers are casual about time. They use “Server Time.” If the server is in California, the logs are in Pacific Time. If they move the server to Virginia, the logs jump forward three hours.

This creates a fractured timeline. Events appear to happen out of order. Effects appear to precede causes. In a legal context, this destroys the credibility of your evidence.

The Risk: The Illusion of Simultaneity.

Consider a contract deadline at midnight. The client in Berlin uploads the document at 23:55 (Berlin time). The server in Chicago records the upload at 16:55 (Chicago time). The lawyer in Sydney sees the file appear at 08:55 the next day.

If the system simply stores “16:55” without the offset, the context is lost. Ten years later, when the audit occurs, no one remembers where the server was located. The timestamp becomes meaningless.

Furthermore, Daylight Savings Time creates a “Duplicate Hour.” At 2:00 AM in autumn, the clock jumps back to 1:00 AM. Events that happened at 1:30 AM happen twice. Which 1:30 AM was it? The Machine crashes on this ambiguity.

The Defense: The Universal Heartbeat.

There is only one time that matters: Coordinated Universal Time (UTC).

This is the time at the Prime Meridian. It never observes Daylight Savings. It never jumps back. It is a monotonic, relentless count of seconds.

To reduce liability, we must enforce a “Time Data Contract”:

1. Storage: The database stores UTC. Always. No exceptions.
2. Format: We use ISO 8601 (2025-12-12T14:30:00Z). This format is sortable by a computer. It ends with a Z (Zulu), indicating UTC.
3. Presentation: We convert to local time only at the very last second, when the pixels are drawn on the user’s screen.

By doing this, we create a timeline that survives the movement of servers and the changing of laws. We create a timeline that is true in Berlin, Chicago, and Sydney simultaneously.

Time is not a decoration to make the report look pretty. It is the anchor of truth. Do not let it drift.

FAQs

Why is local time bad?

Because it changes. Daylight Savings Time deletes an hour of reality once a year. This creates a gap where evidence can hide.

My users hate UTC. It confuses them.

The user interface can *display* local time. But the database must *store* UTC. Do not confuse the presentation with the record.

What is ISO 8601?

It is the international standard for writing time (YYYY-MM-DD). It sorts correctly. It is unambiguous. Use it.