Timezones and UTC: the developer's survival guide

Almost every timezone bug in production traces back to one of five mistakes, and every one of them is avoidable with a small set of rules applied consistently.

Rule 1: store in UTC, always

A timestamp stored as 2026-08-09 14:00:00 with no offset is ambiguous — 2pm where? Store either an ISO 8601 string with an explicit offset (2026-08-09T14:00:00Z) or, better, a Unix timestamp (seconds or milliseconds since epoch), which has no timezone concept at all because it's just a count of elapsed seconds.

// Good: unambiguous, timezone-independent
const createdAt = Date.now(); // 1754748000000
const isoUtc = new Date().toISOString(); // "2026-08-09T14:00:00.000Z"

// Bad: which timezone is this in?
const createdAt = "2026-08-09 14:00:00";

Database columns should be TIMESTAMP WITH TIME ZONE in Postgres (which actually stores UTC internally and converts on display) rather than TIMESTAMP WITHOUT TIME ZONE, which silently drops offset information and inherits whatever the connection's session timezone happens to be.

Rule 2: convert to local time only at the last moment — for display

Do date math, comparisons, and storage in UTC. Convert to the user's local timezone only when rendering to a screen:

new Date(isoUtc).toLocaleString("en-US", { timeZone: userTimezone });

The moment you convert early and then do arithmetic on the local time, you inherit every DST edge case that arithmetic on UTC avoids for free.

Rule 3: UTC offset and IANA timezone are not the same thing

+05:30 is an offset. Asia/Kolkata is a timezone name (an IANA tz database identifier). The critical difference: an offset is a fixed number, but a timezone's offset can change over the year due to daylight saving. Storing "UTC+2" for a European user's preference is a bug waiting for the next DST transition — six months later that offset is wrong. Store "Europe/Berlin" and let a timezone-aware library resolve the correct offset for any given date.

// Bug: fixed offset, breaks across DST
const offset = "+02:00";

// Correct: named zone, offset resolved per-date
const zone = "Europe/Berlin";

Rule 4: date-only values need special handling

A birthday, a deadline, or a "delivery date" is often meant to be timezone-independent — August 9th should mean August 9th no matter where the user is. The classic bug is storing it as a full Date object at midnight UTC and then displaying it in a timezone behind UTC, where midnight UTC on the 9th becomes 7pm on the 8th locally — the date silently shifts backward by a day.

The fix: for pure dates with no time component, store and compare them as plain YYYY-MM-DD strings, or use a date-only type if your database has one (Postgres has DATE), and never round-trip them through a timezone-aware Date object unless you're deliberately attaching a time.

Rule 5: DST arithmetic is not "add 24 hours"

"Tomorrow at the same time" and "add 24 hours" disagree twice a year in any timezone that observes daylight saving. Adding 24 hours to 1:30am on the day before a spring-forward transition can land you on 2:30am or 3:30am depending on the library, while "same time tomorrow" should land on 1:30am the next calendar day. Use a library's calendar-aware "add one day" function, not raw millisecond arithmetic, whenever the operation is meant to be calendar-based rather than duration-based:

import { addDays } from "date-fns";
addDays(new Date("2026-03-08T01:30:00-05:00"), 1); // handles the DST jump correctly

A quick reference for common conversions

• Unix timestamp → human date: multiply by 1000 if it's in seconds (a 10-digit number) before passing to new Date(), which expects milliseconds; a 13-digit number is already milliseconds. Mixing these up is the single most common timestamp bug and produces a date around 1970 or a date far in the future.
• Cross-timezone meeting time: never eyeball offset arithmetic by hand across a DST boundary; convert through UTC and let a library resolve each participant's local time, since two cities' offsets relative to UTC can each shift independently.
• "Today" for a user: compute using the user's timezone, not the server's — a server running in UTC will think it's already tomorrow for a user in California for several hours every day.

The one habit that prevents most of this

Whenever a timestamp crosses a serialization boundary — API response, database write, log line, URL parameter — write down explicitly which format and zone it's in, in the code or the schema comment. Ambiguity is what causes these bugs; an explicit "created_at is Unix ms UTC" comment costs one line and saves the multi-hour debugging session six months later when someone assumes seconds.