JavaScript Time Zone Handling: A Developer's Guide to Dates and Times

JavaScript's Date object was famously designed in 10 days in 1995 by Brendan Eich for Netscape Navigator. It was modeled after Java's java.util.Date, which was itself poorly designed and later mostly deprecated. The result is that handling time zones in JavaScript has been a source of bugs, frustration, and Stack Overflow questions for 30 years. But things are finally improving. Here is what every developer should know in 2026.

The Fundamental Problem with JavaScript Date

The JavaScript Date object stores time internally as a Unix timestamp (milliseconds since January 1, 1970 UTC). When you call methods like getHours() or toString(), the Date uses the user's local time zone (from the operating system) to convert the UTC timestamp into local time. This is convenient but also the source of most bugs. If you parse a date string like 2026-05-14 without specifying a time zone, different browsers interpret it differently (some as UTC, some as local). If you use new Date(year, month, day), it creates the date in the local time zone, which might not be what you intended. If you serialize a Date to JSON with JSON.stringify(), it converts to UTC, but if you parse it back, you might lose the original time zone information.

The Solution: Temporal API

The Temporal API is the long-awaited modern replacement for the Date object. It reached Stage 3 in the TC39 process in 2021 and is available in most modern browsers as of 2025-2026. Temporal provides separate types for different use cases: Temporal.PlainDate for calendar dates without time or time zone, Temporal.PlainTime for wall-clock time without date or time zone, Temporal.PlainDateTime for date and time without time zone, Temporal.ZonedDateTime for date, time, and time zone (the I know exactly when this happened type), Temporal.Instant for an absolute point in time (equivalent to a Unix timestamp), and Temporal.Duration and Temporal.TimeZone for representing lengths of time and time zone rules. The key improvement is that Temporal makes time zone handling explicit rather than implicit and ambiguous.

Intl.DateTimeFormat for Display

For displaying times to users, Intl.DateTimeFormat is the correct tool. It uses the browser's internationalization API to format dates and times according to locale-specific conventions, automatically handling time zone conversion. Key options include timeZone (e.g., 'America/New_York', 'Asia/Tokyo'), dateStyle and timeStyle for predefined formats, and individual component options (year, month, day, hour, minute, second, timeZoneName) for custom formats. Always specify the timeZone option explicitly rather than relying on the default local time zone, especially in server-side rendering where the server's local time zone may not match the user's.

Best Practices for 2026

Store all timestamps as UTC (Unix timestamps or ISO 8601 strings ending in Z). Convert to local time only at the display layer. Use Temporal.ZonedDateTime for all new code. Fall back to libraries like Luxon or date-fns-tz if you need to support older browsers. Never parse date strings without specifying the format and time zone. Use Intl.DateTimeFormat for all user-facing date/time display. Test your code with non-UTC local time zones and across DST transition dates.