Timezone Converter

Coordinating a meeting across timezones is the kind of recurring task that should be one click and isn't. The friction has a single source: dates don't have a timezone built into them. "Tuesday at 10am" is unambiguous if everyone is in the same place; the moment a second person is somewhere else, you need to specify whose 10am. World clock apps show several timezones simultaneously, which helps for "right now" but doesn't answer "what about Tuesday at 10am Pacific?" That's the niche this tool fills.

The input is one wall-clock time in one timezone. The output is the same instant displayed in every other timezone you care about. Browser-native, no server, runs in milliseconds.

**How it works under the hood**. The browser's Intl.DateTimeFormat API ships with the full IANA timezone database — about 400 named regions with their full DST history. Each region has rules like "Standard offset is UTC-8, observes DST on the second Sunday of March through the first Sunday of November". The browser knows these rules and applies them correctly for any date.

To convert "May 15, 2026 at 10:30 in America/Los_Angeles", the tool:

1. Tentatively interprets "May 15, 10:30" as if it were UTC. 2. Asks Intl what that UTC instant looks like in Los_Angeles. 3. Computes the delta between what was wanted and what's seen. 4. Adjusts to find the UTC instant that, when displayed in Los_Angeles, shows "May 15 at 10:30". 5. Formats that UTC instant in each target timezone.

This handles DST correctly: May 15 is during PDT (UTC-7), December 15 would be during PST (UTC-8), and the conversion produces different UTC instants for the same wall-clock string. It also handles the tricky cases — like asking for "March 8, 2026 at 2:30 AM in America/New_York" on the spring-forward day. That time doesn't exist in the local clock; the browser's API handles it by interpreting it as if DST had already begun (3:30 AM EDT) or hadn't yet (1:30 AM EST) — the result is consistent, though potentially surprising. For real-world use you wouldn't usually schedule meetings at those specific minutes.

**Common timezone gotchas**:

- **PST vs PT vs Pacific**. PST is "Pacific Standard Time" — the winter offset. PT is "Pacific Time" — generic, includes both standard and daylight. PDT is the summer one. Lots of meeting invites say "10 AM PST" in July, which is technically wrong (it's actually PDT in July) but everyone knows what they mean. This tool uses IANA names (`America/Los_Angeles`) which automatically pick the right offset for the date.

- **GMT and UTC.** Same offset for practical purposes (UTC is the modern technical standard; GMT is the older designation that's still used in some contexts). The dropdown uses 'UTC' as the reference.

- **India is UTC+5:30**, not UTC+5 or UTC+6. The half-hour offsets (India, Iran, Newfoundland) and quarter-hour offsets (Nepal at UTC+5:45) are real and the browser handles them.

- **China is one timezone**. Despite spanning five geographic timezones, China uses Asia/Shanghai (UTC+8) nationwide for political reasons. Xinjiang in the far west is technically on local time (UTC+6) for some practical purposes but the official timezone is Asia/Shanghai.

- **Anchorage and Honolulu**. Alaska (UTC-9) and Hawaii (UTC-10) are easy to forget when scheduling for "the US"; Hawaii doesn't observe DST so the offset to mainland US shifts by an hour between winter and summer.

**The Common Timezones dropdown** covers the 30 most-frequently used zones — UTC, the main US zones, the main European zones, the main Asia/Pacific zones, plus a few extras. For other zones, the browser's Intl support is for the full IANA list; if you need to support an obscure zone, the easiest workaround is to find the IANA name and add it to the registry.

**Auto-detection of local timezone**. On first load, the tool reads your browser's local timezone (via `Intl.DateTimeFormat().resolvedOptions().timeZone`) and uses it as the default source TZ. If your local zone isn't in the common-30 dropdown, the tool falls back to UTC. The detected local zone is shown as a hint so you can confirm or adjust.

**Display format**. Each target timezone shows the converted time in a human-readable form: `Wed, May 14, 2026, 10:30 AM EDT`. Day of week, date, time, and the abbreviated timezone code are all included so you can quickly scan for "is this Tuesday or Wednesday in that zone?" The format is locale-appropriate (uses en-US conventions for the page audience).

**Privacy**. Browser-native. No network. The Intl timezone database ships with the browser; the conversion logic is JavaScript in your tab. Verify in DevTools by watching the network panel stay empty during conversion. Useful when you're scheduling meetings about confidential topics — the meeting times don't get logged by a third-party time-zone service.

**Edge cases handled correctly**: DST transitions (both spring-forward and fall-back), half-hour offsets (India, Iran, Newfoundland), Pacific island zones with unusual offsets (Tonga, Kiribati), year-end transitions where the new local day starts before the new UTC day, leap days (Feb 29 is handled by Intl natively).