Why time-zone math is harder than it looks
A time zone is not a fixed offset from UTC. It's a region's politically-chosen offset, which changes due to daylight saving rules, government decisions, and historical adjustments. The IANA Time Zone Database (used by JavaScript, Python, and most modern languages) tracks all of these — over 600 zones, each with its full historical offset table.
A "fixed" question like "what's the time in New York" actually depends on the moment you're asking. In summer it's UTC-4 (EDT); in winter UTC-5 (EST); before 2007 the DST transition dates were different. The browser's built-in Intl.DateTimeFormat uses the IANA database underneath, so it handles all this correctly — but only if you ask in terms of zones (like America/New_York) rather than UTC offsets.
IANA names vs abbreviations
Always prefer IANA zone names (America/New_York, Europe/Paris) over abbreviations (EST, CET). Abbreviations are ambiguous: CST can mean Central Standard Time (US, UTC-6), China Standard Time (UTC+8), or Cuba Standard Time. BST is British Summer Time, Bangladesh Standard Time, or Bougainville Standard Time. The IANA name is unambiguous.
When storing dates in a database, store UTC and convert on display. When scheduling future events at "the user's 9 AM", store the zone name AND the local time — not a UTC instant — because DST rule changes can shift the UTC instant of a future local time after you've stored it.
Common JavaScript patterns
// Current time in any IANA zone
new Intl.DateTimeFormat('en-US', {
timeZone: 'America/New_York',
dateStyle: 'full',
timeStyle: 'long',
}).format(new Date())
// ISO string in a specific zone (gets the offset right)
new Date().toLocaleString('sv', { timeZone: 'Asia/Tokyo' })
// "2026-05-20 14:30:00" (Swedish locale uses ISO-ish format)
// Get the user's zone (where available)
Intl.DateTimeFormat().resolvedOptions().timeZone
// "America/New_York" or wherever you are
// Compare two zones safely: convert both to UTC instants
const a = new Date('2026-12-25T09:00:00-05:00');
const b = new Date('2026-12-25T15:00:00+01:00');
a.getTime() === b.getTime() // true — same UTC moment
Common use cases
- Schedule meetings across multiple time zones
- Convert a deployment window from UTC to local time
- Verify a cron expression in UTC will run at the expected local time
- Find a working hour overlap between distributed teams
Frequently asked questions
Why prefer IANA names over abbreviations?
Abbreviations are ambiguous. CST = Central US (UTC-6), China (UTC+8), or Cuba. BST = British Summer, Bangladesh Standard, or Bougainville Standard. IANA names like <code>America/New_York</code> are unambiguous and include the full DST history.
How does the browser know all these time zones?
The browser ships with the IANA Time Zone Database (tzdata). The <code>Intl.DateTimeFormat</code> API uses it for conversions. Tzdata is updated periodically as governments change their time-zone rules; modern browsers update it via their normal updates.
What about historical dates?
IANA tracks historical offset rules — DST didn't exist before 1916; many countries changed their rules in 2007, 1996, 1973, etc. The browser handles all this correctly. A meeting "at 9 AM Eastern" in 1985 was UTC-5; the same in 2026 is UTC-5 in winter, UTC-4 in summer.
How do I store time zones in a database?
For past timestamps: store as UTC (ISO 8601 with Z suffix). For future events at a local time: store the IANA zone AND the local datetime; convert at display time. Don't store offsets — they're not stable across DST and rule changes.