data.day
checklist / operations / data integrity

The Timezone Checklist for Forms, Spreadsheets, and PDFs

A practical guide to stopping time-based data corruption. Use this checklist before you design your next form or report.

Lars Parse Lars Parse

The Missing Coordinate

When we design a form—an incident report, a vacation request, a delivery receipt—we ask: Who? What? When?

The “When” field is the most common point of failure.

We place a calendar widget on the screen. The user picks “Oct 12, 4:00 PM.” We save it.

Later, we calculate the Service Level Agreement (SLA). “We must respond within 4 hours.” The support team is in California. The user is in London. The system calculates the difference between 4:00 PM (London) and 5:00 PM (California). It thinks we responded in 1 hour. In reality, we responded in 9 hours. We missed the SLA. We owe a penalty.

The data was incomplete. We captured the hands of the clock, but not the wall the clock hangs on.

The Risk: The Silent Drift.

This risk is insidious because the system does not crash. It creates silent errors. Reports generated for the CEO show excellent performance. The client experiences terrible performance.

Ambiguity creates a gap between the metric and the reality. Disputes cost money.

The Defense: The Timezone Checklist.

Before you launch any form, spreadsheet, or PDF workflow, apply this checklist.

1. The Capture Layer:

  • Does the form explicitly ask for the Timezone?
  • If not, does the system automatically capture the browser’s timezone offset (e.g., UTC-5) in a hidden field?
  • Is the field label unambiguous? (Instead of “Time”, use “Your Local Time”).

2. The Storage Layer:

  • Does the database column store the offset or is it normalized to UTC? (e.g., timestamp with time zone in Postgres).
  • Do we persist the original offset for context? (Sometimes we need to know it was “morning for the user” even if it was night for the server).

3. The Presentation Layer:

  • When we print the PDF, do we append the timezone abbreviation? (16:00 EST).
  • When we export to Excel, is the column ISO 8601 formatted? (2025-10-12T16:00-05:00).

4. The Logic Layer:

  • Are all duration calculations (Time B minus Time A) performed in UTC? Never subtract local times directly.

If you cannot check these boxes, your form is not a tool for truth. It is a generator of confusion. Fix the input, and the output will defend itself.

FAQs

Can't we just detect the user's IP address?

No. An IP address tells you where the internet connection is, not what time it is. VPNs make this data useless.

What if the user doesn't know their timezone?

They know their city. Ask for the city. The Machine can derive the timezone from the city (e.g., 'Europe/Paris').

Is this overkill for internal forms?

If your company has one office, maybe. If you have remote workers, absolutely not. Remote work destroys the assumption of shared time.