Skip to main content

Prefer Explicit Timezones Over "Server Local"

Updated 2 min readMarkdown

"Server local time" is one of those phrases that sounds practical until it is not.

It works fine on a laptop. It works less fine when your app runs in three regions, a cron job runs in UTC by default, and a teammate in another zone opens a dashboard at 11pm and swears the report is wrong.

If a timestamp matters, store and transmit it with an explicit timezone. Prefer UTC for storage and conversion at the edges. If a user sees a time, show it in their zone, labeled. If a job must run at 9am in India, say Asia/Calcutta in the schedule, not "whatever the box clock happens to be."

A few habits that save pain:

  1. Never parse a bare local datetime as if everyone shares one wall clock. 2026-10-16 14:30 without a zone is unfinished data.
  2. Name the zone in configs and cron. CRON_TZ=Asia/Calcutta beats tribal knowledge.
  3. Log both. When debugging, print UTC and the intended local zone. Arguments end faster.
  4. Treat "server local" as a smell. It usually means the code assumed a single machine would always be home.

Time bugs feel mystical because they appear only after deploys, daylight saving changes, or a new region. Explicit zones make them boring. Boring is the goal.

Your future on-call self does not want a mystery. They want a timezone.

About the author

No comments yet. Be the first to comment.