Timezone-Correct Date Formatting in JavaScript Without Libraries

Why Date has no timezone property

A JavaScript Date is always a UTC millisecond count. There is no timezone stored inside the object. When you call .toString() or .toLocaleString() without options, JavaScript uses the runtime's local timezone from the operating system. The same code produces different output on a server in New York vs a laptop in Tokyo, even though the underlying timestamp is identical.

Formatting with Intl.DateTimeFormat

Intl.DateTimeFormat is the built-in API for locale- and timezone-aware formatting. It supports IANA timezone identifiers, handles DST transitions automatically, and is available in modern browsers and Node.js. The key is to pass the timeZone option explicitly instead of relying on the runtime default.

• new Intl.DateTimeFormat('en-US', { timeZone: 'America/New_York', dateStyle: 'full', timeStyle: 'long' }).format(date)
• date.toLocaleString('en-GB', { timeZone: 'Europe/London', hour12: false })
• date.toLocaleString('ja-JP', { timeZone: 'Asia/Tokyo' })
• new Intl.DateTimeFormat('en-US', { timeZone: 'UTC', hour12: false }).format(date)

Extracting individual parts with formatToParts

Use formatToParts() to get individual date components as {type, value} objects for custom date string construction. This is better than splitting a localized date string because punctuation, ordering, and scripts differ by locale.

• const parts = new Intl.DateTimeFormat('en-US', { timeZone: 'America/Chicago', year: 'numeric', month: '2-digit', day: '2-digit' }).formatToParts(date)
• parts.find(p => p.type === 'year').value → '2023'
• parts.find(p => p.type === 'month').value → '11'
• Object.fromEntries(parts.map(p => [p.type, p.value])) → { year, month, day, hour, minute, second }

Converting wall-clock time to UTC (the hard direction)

Going from a wall-clock time in a given timezone to UTC is harder with the classic Date API. Formatting an instant into America/New_York is easy; constructing the instant represented by 2026-03-08 02:30 in America/New_York is not, because that local time may be skipped or repeated during daylight saving transitions.

• Temporal reached Stage 4 in 2026, but native browser support is still not universal
• For production use across all browsers today, the Temporal polyfill or date-fns-tz toDate() are still practical choices
• Avoid manual UTC offset arithmetic — DST transitions happen at different local times in different years
• This site's zonedToEpochMs() uses one-iteration offset correction — see src/timeUtils.ts

Choosing the right timezone identifier

Use IANA timezone names such as America/New_York, Europe/London, Asia/Tokyo, or UTC. Avoid fixed offsets like UTC-5 for user-facing time because offsets change with daylight saving time. America/New_York can be UTC-5 in January and UTC-4 in July; the IANA name lets the platform apply the correct historical rule for the selected date.

• Good: America/Los_Angeles — includes historical and future DST rules
• Good: Europe/Berlin — handles Central European Summer Time automatically
• Good: Asia/Shanghai — stable UTC+8 display without DST
• Use UTC for logs, API storage, database timestamps, and cross-region comparison
• Use the user's IANA timezone for final display in the product UI

Timezone formatting FAQ

Can JavaScript format a date in another timezone without a library?

Yes. Use Intl.DateTimeFormat or toLocaleString with a timeZone option, such as America/New_York or Asia/Tokyo.

Does Intl.DateTimeFormat handle daylight saving time?

Yes. When you use an IANA timezone identifier, the runtime applies the correct offset for that timezone and date.

Should I store timezone offsets or timezone names?

Store UTC for event instants. If you need the user's local context, store an IANA timezone name such as America/New_York, not only a numeric offset.

How do I get the user's timezone in JavaScript?

Use Intl.DateTimeFormat().resolvedOptions().timeZone, which returns an IANA name like America/New_York. Store that name, not a numeric offset, when you need to reconstruct the user's local time later.