Handling Timezones in Web Applications

Table of Contents

• The Golden Rule
• UTC vs Local Time
• Storing Dates in the Database
• Displaying in User's Timezone
• The DST Problem

The Golden Rule

Always store and transmit dates in UTC. Convert to local time only for display.

If you store a date in a user's local timezone, you'll have bugs the moment they travel, change their device timezone, or your system processes dates on a different server.

UTC vs Local Time

const now = new Date();

now.toISOString();     // '2025-02-22T14:30:00.000Z' — UTC, unambiguous
now.toLocaleString();  // '2/22/2025, 10:30:00 PM' — depends on OS timezone

Storing Dates in the Database

-- Use TIMESTAMPTZ in PostgreSQL — stores UTC, converts for display
created_at TIMESTAMPTZ DEFAULT NOW()

-- Avoid TIMESTAMP without timezone — ambiguous when reading

Displaying in User's Timezone

const utcDate = new Date('2025-02-22T14:30:00Z');

// Display in Tokyo
utcDate.toLocaleString('ja-JP', { timeZone: 'Asia/Tokyo' });
// '2025/2/22 23:30:00'

// Display in New York
utcDate.toLocaleString('en-US', { timeZone: 'America/New_York' });
// '2/22/2025, 9:30:00 AM'

The DST Problem

Daylight Saving Time causes clocks to jump forward/backward, creating ambiguous or non-existent times.

If you schedule recurring events (e.g. 'every day at 9am'), store the timezone name (America/New_York), not the UTC offset (+05:00), since the offset changes with DST.