Time Utilities

Timezone Converter

Convert date and time from one timezone to another.

What is Timezone Converter?

Timezone converter transforms times between different time zones, essential for international coordination.

Features

  • 200+ time zones supported
  • DST (Daylight Saving Time) aware
  • Multiple time comparison

Use Cases

  • Meeting scheduling across time zones
  • International business coordination
  • Travel planning

A timezone converter turns a wall-clock date and time in one zone into the same instant expressed in another, resolving offsets through IANA zone names rather than fixed numbers so daylight saving changes follow automatically. It fits cross-border meeting scheduling, reading logs that are stamped in UTC, and checking which date a release lands on elsewhere.

Where the offset number comes from

The converter stores no offset table. For each side it calls Intl.DateTimeFormat with timeZoneName: "shortOffset" and parses the label that comes back - GMT+8, GMT-5, GMT+5:30 - into a signed count of minutes. Because the lookup is per instant rather than per zone, Shanghai reports +8 all year while New York reports -5 in January and -4 in July. The rules behind that label live in the IANA time zone database bundled with the browser build, not in this page, so a stale browser keeps applying rules that have since changed: a country dropping daylight saving, a zone split in two, a border redrawn. Updating the browser is what corrects the offset; the page cannot.

The daylight saving hour that does not exist

Wall-clock input carries no offset, so the tool turns it into a provisional instant with Date.UTC, reads the source offset at that instant, and subtracts it once. A single pass is right except inside the two transition hours each year. Enter 2025-03-09 02:30 as America/New_York, a reading skipped when clocks jump from 02:00 to 03:00, and the result is 2025-03-09T07:30:00.000Z; in New York that instant is 03:30 EDT, an hour later than what was typed. Autumn mirrors it: 01:30 on 2025-11-02 occurs twice locally, and the tool commits to the earlier, still-EDT instant 2025-11-02T05:30:00.000Z. Libraries that get both cases right re-read the offset after adjusting; this one-pass code does not iterate.

Accepted shapes, and overflow it repairs silently

Only two shapes reach the wall-clock branch: YYYY-MM-DD HH:MM and YYYY/M/D HH:MM, date and time separated by a space, seconds optional, four-digit year required. Anything else - a T separator, a trailing Z, +08:00, a bare date - is handed to new Date() and reconciled against the browser zone instead, which can land many hours from the intended instant. Within the accepted shapes there is no calendar check: Date.UTC normalises overflow instead of refusing it, so 2025-02-31 10:00 quietly becomes March 3, and 25:99 rolls forward to 02:39 the next morning before any offset is applied.

Worked example

Shanghai afternoon to a New York morning

Input 
2025-01-30 14:00 - source Asia/Shanghai, target America/New_York
Output 
Jan 30, 2025, 01:00:00 / 2025-01-30T06:00:00.000Z

Shanghai is UTC+8 in January, so 14:00 minus eight hours is 06:00 UTC, and New York on EST (UTC-5) reads 01:00 the same date. The second line comes from toISOString() and therefore always prints UTC, not the target zone - do not paste it into a calendar invite as if it were EST.

Limits and pitfalls

  • Both pickers are fixed lists of ten IANA ids (UTC, Asia/Shanghai, Asia/Hong_Kong, Asia/Tokyo, America/New_York, America/Los_Angeles, America/Chicago, Europe/London, Europe/Paris, Australia/Sydney); Asia/Kolkata or Europe/Berlin cannot be typed in.
  • Only YYYY-MM-DD HH:MM[:SS] and YYYY/M/D HH:MM are read as wall-clock time in the source zone; a T separator with a Z or numeric offset suffix is parsed against the browser zone and can land many hours away.
  • No calendar validation: impossible dates and out-of-range clock fields roll over without a warning, so 2025-02-31 10:00 reports March 3.
  • The localised line carries no offset or zone abbreviation and the ISO line is always UTC, so neither output can be quoted without naming the target zone yourself.
  • Daylight saving edges are not flagged: a time inside the spring-forward gap slides an hour later, and the repeated autumn hour resolves to the earlier daylight-time instant.

Related tools

When it goes wrong

The current-time button fills in my laptop clock, not the source zone I picked

CauseloadExample builds the string with new Date().toLocaleString("zh-CN", …) in the browser zone and only swaps / for -; the source select is never read, and seconds are dropped on the way.

FixPress it only when the source zone is the zone this browser sits in; otherwise read the source city on the world clock and type that value, or move the source select to your own zone before pressing.

My colleague and I type the same string and get clocks hours apart

CauseThere are two paths. A space-separated YYYY-MM-DD HH:MM goes through Date.UTC and is machine-independent; anything else is parsed by new Date() and then corrected by d.getTimezoneOffset(), so the string is first read as this browser wall clock before the source offset is subtracted.

FixStrip the T, any trailing Z or +08:00, and any comment, leave exactly one space between date and time, then compare the ISO lines - under that shape they agree for everyone.

I typed 2025/1/30 9:05 PM and it came back as 9:05 in the morning

CauseThe slash pattern has no $ anchor, so everything past the minutes is discarded silently - PM, a trailing UTC, anything. The dash pattern does end in $, so the same tail drops the whole string into new Date(), where the outcome is the browser's business.

FixWrite 21:05 and keep the field to date, one space, time; declare the zone with the dropdown instead of appending words to the string.

Switching the target from UTC to Europe/London changed nothing

CauseOffsets are looked up per instant, not per zone. In January the London label is GMT with no sign at all, it never matches the GMT+/GMT- pattern, and getOffsetMinutes falls through to return 0 - the same number UTC hands back.

FixTry a July date, when London is UTC+1, or compare Europe/Paris against UTC, which differs in both seasons; if the two lines differ only in wording, those zones genuinely share an offset at that instant.

I type into the box and nothing appears under it

CauseThe widget is a client:idle Vue island inside an Astro page: before the bundle hydrates, or with scripts blocked, the input is inert markup around the placeholder 2025-01-30 14:00 and the result panel never mounts. An empty field also returns null, so the panel stays hidden.

FixAllow JavaScript for the page and let the island hydrate; if you need a script-free conversion, compute it in the browser console or on the server instead.

Ten fixed zones, one pair per run: when this page is the right stop

DecisionThis converterWhere to go instead
The city you need is not one of the ten in the dropdownBoth sides are plain <select> elements over ten hard-coded IANA ids, so Kolkata (UTC+5:30), Berlin, Seoul or São Paulo cannot be entered at all - there is no text field and no search box.Read the offset directly with Intl.DateTimeFormat("en-US", { timeZone: "Asia/Kolkata", timeZoneName: "shortOffset" }) in the console and subtract it yourself, or reach for a library such as Luxon, which takes any IANA id.
The time you were handed is already an ISO string with Z or +08:00Only a space-separated wall-clock reading stays on the clean path. 2025-01-30T06:00:00Z is pushed through new Date() and then re-anchored by the browser offset, so the answer can sit the better part of a day away from the instant the string names.The ISO 8601 tool parses that string as written and prints the UTC instant plus epoch milliseconds; take those two numbers and do the zone arithmetic once, yourself.
You want "what time is it there right now" for several peopleOne source and one target per run, and the current-time button inserts your own machine clock, so a five-person call costs four rounds of retyping and copying.The world clock shows eight zones ticking every second in a single view - but it accepts no date at all, so it only answers the "now" question.
You need the numeric gap between zones for a rule or an assertionThe panel prints two formatted strings and never a signed offset, so a cron window or a test expectation has to be reverse-engineered from the displayed clock.Run the same instant through the timestamp tool, subtract the two epoch values and divide by 3600000 for hours; for whole days or working days use the date calculator instead.
The result lands in a calendar invite, a doc or a fixtureThe localized line carries no offset and no abbreviation, and the ISO line is the UTC instant, so a bare 10:00 means nothing to a reader who does not already know the zone.Format with the zone attached - Temporal.ZonedDateTime or Luxon toISO() yields 2025-01-30T01:00:00.000-05:00; if you must use this page, copy the localized line and type the zone name beside it, never the ISO line.
The same conversion has to run in CI or on a serverThe conversion lives in a client:idle Vue island inside the tab, with no API and no CLI, so a build step has nothing to call.Node ships full ICU and runs the identical Intl call, but the offsets come from the runtime build, so pin the Node/ICU version or the numbers drift after an image upgrade.

Frequently Asked Questions

How should I schedule a cross-timezone meeting?
Three steps: fix an anchor instant in UTC → have each participant confirm in their local zone → state the timezone explicitly in the invite (or annotate UTC). The side-by-side view instantly exposes conflicts like "10 a.m. in Shanghai is 10 p.m. the previous night in New York".
Are UTC, GMT, and Z the same thing?
Colloquially interchangeable. Strictly, GMT is the astronomical legacy based on Earth’s rotation; UTC is the atomic-clock standard with leap-second corrections; Z is the aviation/military spelling of UTC. In code, standardize on UTC and ignore the physical distinction.
What are the classic daylight-saving pitfalls?
Three: spring-forward times (2:30 a.m.) do not exist; fall-back times occur twice; and regions occasionally abolish DST, creating ambiguous history. The takeaway: store UTC plus a timezone identifier (America/New_York), never a fixed local offset.

Content reviewed: