See one moment rendered in two time zones side by side — DST-aware via the IANA database, across nine major zones including UTC and IST.
Content last reviewed
Pick the moment to compare — the date matters because daylight saving shifts offsets during the year.
Select the From and To time zones from the nine available.
The same instant is displayed in each zone's local date and time, side by side.
The default pairing: an Indian afternoon rendered on the US East Coast, DST-aware for the date.
Input
July 15, 3:00 PM (your local clock) · From: Asia/Kolkata · To: America/New_YorkOutput
Both panels show the same instant — e.g. Jul 15, 3:00 PM in Kolkata alongside Jul 15, 5:30 AM in New York (a 9.5-hour gap during US summer time)London–New York is 5 hours apart most of the year but 4 in late March, because the regions switch on different dates.
Input
The same wall-clock time checked on March 20 and March 30 · Europe/London ↔ America/New_YorkOutput
The rendered gap differs by an hour between the two dates — the reason date-aware conversion matters"Let's meet at 4pm" is meaningless until everyone knows whose 4pm. Remote teams, freelancers with overseas clients, families across countries, and anyone catching a global launch all hit the same problem: what does a given moment look like on two different clocks — including daylight saving, which shifts the answer during the year.
This converter takes a date and time and two time zones, and renders that single instant in both zones side by side. It works from the IANA timezone database built into your browser — the same rules operating systems use — so DST transitions apply automatically for the specific date you choose. That is the detail mental arithmetic gets wrong: London and New York are 5 hours apart most of the year but 4 hours for a few weeks each spring, because the two regions switch to summer time on different dates.
Nine zones cover the major hubs: UTC, New York, Los Angeles, London, Berlin, Kolkata (IST, the half-hour offset that defeats add-N-hours arithmetic), Tokyo, Singapore, and Sydney. One usage note: the date-time you enter is read in your device's local timezone, and both panels then display that same instant — so the natural workflow is to enter the moment as it is on your own clock and read what it becomes elsewhere. For a moment announced in another zone, adjust the input until that zone's panel shows the announced time, then read your own. Once resolved, the Countdown Timer can track it.
Enter the date and time — it is interpreted on your device's local clock. Including the date matters, since daylight-saving rules depend on it.
Pick the From and To time zones from the dropdowns — UTC, America/New_York, America/Los_Angeles, Europe/London, Europe/Berlin, Asia/Kolkata, Asia/Tokyo, Asia/Singapore, or Australia/Sydney.
Read the two panels: the same instant rendered in each zone's local date and time.
To convert a time announced in another zone, adjust the input until that zone's panel shows the announced time — your own zone's panel then shows the local equivalent.
For recurring meetings, sanity-check one summer date and one winter date; if either region observes DST, the gap shifts by an hour between them.
Conversions use the browser's built-in timezone rules, so daylight saving applies correctly for the exact date chosen.
The same instant rendered in both selected zones, with full date and time — day rollovers are impossible to miss.
UTC plus New York, Los Angeles, London, Berlin, Kolkata, Tokyo, Singapore, and Sydney — including the UTC+5:30 half-hour offset.
Because the date is part of the input, spring/autumn offset shifts between the same two cities resolve automatically.
See what a proposed slot on your clock means for a colleague in another hub.
Work out the local time of a launch, keynote, or market open announced elsewhere.
Pin down what "end of day UTC" or "9am ET" means for your team.
Check both clocks before dialling across continents.
The entered date-time is parsed on your device's local clock into a single absolute instant, and that instant is then formatted in each selected zone using the browser's internationalization engine — which carries the full IANA timezone database, including every region's daylight-saving rules and their historical changes.
This is why the converter needs no offset tables and never goes stale on DST: asking "what is this instant in America/New_York" delegates to the same rules your operating system uses. It is also why half-hour zones like Asia/Kolkata (UTC+5:30) come out right — the zone's real rules apply, not hour-based arithmetic.
A single datetime field, interpreted in your device's local timezone.
Two dropdowns over nine IANA zones: UTC, New York, Los Angeles, London, Berlin, Kolkata, Tokyo, Singapore, Sydney.
The input is read on your device's local clock, and the panels render that instant per zone — so the From panel matches your typed time only when From is your own zone. To convert an announced foreign time, adjust the input until the foreign zone's panel shows it.
One side crossed a daylight-saving boundary. Re-check the conversion with the actual meeting date — the same two zones can be 4 or 5 hours apart depending on the week.
Nine hub zones are available. Pick the zone that shares your city's rules (much of western Europe matches Berlin; many US cities match New York or Los Angeles) — sharing an offset and DST regime is what matters.
The zone list covers nine major hubs rather than every region — cities sharing a listed zone's rules convert exactly, others need the closest rule-match. The input is interpreted on your device's local clock (not in the From zone), which shapes the workflow for foreign-announced times as described above. Only two zones display at once; comparing five cities means repeated pairings. Rules come from the browser's IANA data, which browsers keep current with OS updates.
Everything is computed by your browser's built-in date engine — no times, zones, or schedules are uploaded or stored.
Always convert with the real event date — DST makes the same two cities differ by season.
State the zone explicitly when inviting others (e.g. 15:00 IST), using city or IANA names over abbreviations.
Check the date in both panels, not just the time — day rollovers across the Pacific are routine.
Re-verify standing meetings after March and October, when most DST switches land.
Publish global events in UTC and let each attendee convert.
Anchor every cross-zone plan to one unambiguous statement: a time plus an IANA zone (or UTC). "4pm" travels badly; "16:00 Europe/London" converts mechanically anywhere. This tool is the mechanical step — the discipline is writing times that way in the first place.
Convert on the event's actual date, every time. The single largest class of missed international meetings comes from offsets memorized in one season and reused in another; the few weeks each year when only one side has switched to summer time are precisely when "I know the offset" fails.
And for recurring calls between DST-observing and non-observing regions (a London–Bengaluru standup, say), accept that one side's local time will shift twice a year — decide in advance which side holds constant, and re-announce at each switch.
The datetime-local input parses to an absolute instant on the device clock; each panel formats that instant with Intl.DateTimeFormat and an explicit timeZone option, drawing on the browser's IANA tz database for offsets and DST rules. No offset arithmetic is hand-rolled, and invalid states render as a placeholder rather than an error. Fully client-side.
Remote workers and freelancers scheduling across offices, event-watchers converting launch times, families spread across continents, and anyone burned once by a DST-shifted meeting. For a moment you have already resolved to local time, the Countdown Timer takes over.
Yes — that is the main reason to use it over mental math. Each zone's DST rules apply for the exact date entered, via the IANA database, which is why the same two cities can be 4 hours apart in March and 5 in December.
An offset (UTC+5:30) is a fixed number; a timezone (America/New_York) is a rulebook whose offset changes through the year. Converting with a fixed offset silently breaks around DST switches — this tool converts by zone rules instead.
Set From to the announcing zone and adjust the date-time input until that panel shows the announced time — your zone's panel then reads the local equivalent. The input itself is interpreted on your device's clock, which is why the adjustment step exists.
Not all offsets are whole hours — India runs at UTC+5:30, for example. The converter handles it because it applies real zone rules rather than hour-based addition; Kolkata is one of the nine built-in zones.
The zone that shares your rules: most of central-western Europe matches Berlin, the UK matches London, US Eastern cities match New_York, and so on. Matching offset plus DST regime gives identical conversions.
UTC, or your own zone labelled with its IANA/city name. Ambiguous abbreviations like CST (three meanings worldwide) are how attendees end up an hour — or a continent — off.