About

UTC offsets introduce a single, persistent class of error in distributed systems and scheduling: the wrong meeting time, the misattributed log entry, the missed deployment window. This tool parses raw UTC date strings - ISO 8601, RFC 2822, Unix timestamps in seconds or milliseconds - and converts them to any of the 400+ IANA timezone identifiers supported by the browser's Intl API. It does not guess your format. It tries multiple parsers in priority order and uses the first valid parse. The conversion is performed entirely by the runtime's DateTimeFormat engine, which accounts for historical DST transitions and political timezone boundary changes stored in the ICU dataset.

Limitations: sub-second precision is truncated to milliseconds. Leap seconds are not represented in JavaScript's Date object. Dates before the Unix epoch (1970-01-01) are supported but may exhibit platform-dependent behavior for pre-Gregorian calendar dates. Pro tip: if you are pasting from a database log, check whether the timestamp includes a timezone indicator. A bare datetime like 2024-01-15 14:30:00 without a trailing Z or offset is ambiguous and will be treated as UTC by this tool, which may not match your source system's interpretation.

Formulas

The conversion relies on JavaScript's Intl.DateTimeFormat constructor with a specified timeZone option. Internally, the engine computes the target local time from the UTC epoch milliseconds value stored in the Date object.

T_target = T_UTC + Δ_offset(tz, T_UTC)

Where T_UTC = the input time as UTC epoch milliseconds, Δ_offset = the timezone offset function that returns the correct offset in milliseconds for timezone tz at the specific instant T_UTC. This offset is not a constant - it varies with DST rules, which change historically. The browser's ICU database encodes these transitions.

For Unix timestamp detection, the parser checks whether the input is a pure numeric string. If the value is less than 1 × 10¹², it is interpreted as seconds since epoch. If greater, it is interpreted as milliseconds.

{

T_ms = n × 1000 if n < 10¹²T_ms = n if n ≥ 10¹²

Where n = the parsed numeric input and T_ms = epoch milliseconds passed to the Date constructor.

Reference Data

Timezone (IANA)	Abbreviation	UTC Offset (Standard)	UTC Offset (DST)	Region
America/New_York	EST / EDT	−05:00	−04:00	US East Coast
America/Chicago	CST / CDT	−06:00	−05:00	US Central
America/Denver	MST / MDT	−07:00	−06:00	US Mountain
America/Los_Angeles	PST / PDT	−08:00	−07:00	US West Coast
America/Anchorage	AKST / AKDT	−09:00	−08:00	Alaska
Pacific/Honolulu	HST	−10:00	No DST	Hawaii
Europe/London	GMT / BST	+00:00	+01:00	United Kingdom
Europe/Berlin	CET / CEST	+01:00	+02:00	Central Europe
Europe/Moscow	MSK	+03:00	No DST	Russia West
Asia/Dubai	GST	+04:00	No DST	Gulf States
Asia/Kolkata	IST	+05:30	No DST	India
Asia/Kathmandu	NPT	+05:45	No DST	Nepal
Asia/Shanghai	CST	+08:00	No DST	China
Asia/Tokyo	JST	+09:00	No DST	Japan
Australia/Sydney	AEST / AEDT	+10:00	+11:00	Australia East
Australia/Adelaide	ACST / ACDT	+09:30	+10:30	Australia Central
Pacific/Auckland	NZST / NZDT	+12:00	+13:00	New Zealand
Pacific/Chatham	CHAST / CHADT	+12:45	+13:45	Chatham Islands
America/Sao_Paulo	BRT	−03:00	No DST	Brazil East
America/Argentina/Buenos_Aires	ART	−03:00	No DST	Argentina
Africa/Cairo	EET	+02:00	No DST	Egypt
Africa/Nairobi	EAT	+03:00	No DST	East Africa
Asia/Singapore	SGT	+08:00	No DST	Singapore
Asia/Hong_Kong	HKT	+08:00	No DST	Hong Kong
Europe/Istanbul	TRT	+03:00	No DST	Turkey
America/Phoenix	MST	−07:00	No DST	Arizona (no DST)
Asia/Calcutta	IST	+05:30	No DST	India (alias)
Pacific/Fiji	FJT / FJST	+12:00	+13:00	Fiji
Atlantic/Reykjavik	GMT	+00:00	No DST	Iceland
Pacific/Tongatapu	TOT	+13:00	No DST	Tonga (UTC+13)

Frequently Asked Questions

A bare datetime string with no trailing Z, UTC suffix, or numeric offset is inherently ambiguous. This tool assumes UTC for all ambiguous inputs. If your source system stores local times without an indicator, you must append "Z" or "+00:00" manually if the value is truly UTC, or select the source timezone and mentally reverse the conversion. The JavaScript Date constructor's behavior with bare strings is browser-dependent - some treat it as UTC, others as local time. This tool normalizes by explicitly appending "Z" to bare ISO-like strings before parsing.

The offset function Δ_offset is not a constant. It depends on the Daylight Saving Time rules in effect at the specific instant being converted. America/New_York is UTC−05:00 during standard time (EST, roughly November through March) and UTC−04:00 during daylight time (EDT, roughly March through November). The exact transition dates have changed historically - for example, the US Energy Policy Act of 2005 extended DST starting in 2007. The browser's ICU timezone database encodes these historical transitions.

JavaScript's Date object supports timestamps up to ±8,640,000,000,000,000 milliseconds from the epoch, which corresponds to approximately ±273,790 years. Any numeric input producing a Date that returns NaN from getTime() is rejected as invalid. Practically, timestamps beyond year 9999 may render oddly in formatted output due to 4-digit year assumptions.

No. JavaScript's Date object does not model leap seconds. UTC as implemented in ECMAScript uses a day length of exactly 86,400 seconds. The 27 leap seconds inserted between 1972 and 2017 are invisible. If you are working with TAI (International Atomic Time) or GPS time, you must add the cumulative leap second offset externally. For most scheduling and logging use cases, this discrepancy is irrelevant.

The parser attempts multiple format patterns. However, the DD/MM/YYYY vs MM/DD/YYYY ambiguity is fundamentally unresolvable for dates where the day is 12 or less (e.g., "05/06/2024" could be May 6 or June 5). This tool prioritizes ISO 8601 (YYYY-MM-DD) and falls back to the browser's native Date.parse() for other formats, which typically uses the US convention (MM/DD/YYYY). If your logs use DD/MM/YYYY, reformat to ISO 8601 before pasting for unambiguous results.

Timezone offsets are political decisions, not mathematical necessities. India adopted UTC+05:30 as a single zone to unify the subcontinent. Nepal chose UTC+05:45 to differentiate from India. The Chatham Islands use UTC+12:45. Historically, some zones used offsets to the second (e.g., Amsterdam was UTC+00:19:32 before 1940). The IANA database encodes all of these. The Intl.DateTimeFormat API handles them correctly.