Timezone Converter

Pick a date, a wall-clock time, a source timezone, and a destination, and the converter returns the matching local date and time on the other side. Both selectors accept any IANA timezone name, so daylight saving, half-hour offsets, and historical zone changes all resolve from the tz database rather than a fixed offset. Use it to schedule a call across continents, decode a server log written in UTC, or check what 09:00 in New York looks like in Tokyo on a specific date. Pair the result with the meeting planner when you need overlapping work hours for a recurring meeting.

Common use cases

Scheduling a cross-continent call. A New York product manager and a Tokyo engineer need to find 09:00 New York in local Tokyo time for a kickoff. Enter the date, 09:00, America/New_York, and Asia/Tokyo, and the result is the wall-clock time the Tokyo side should put on the calendar.
Reading a UTC server log in your own zone. Production logs commonly land in UTC. Drop the UTC timestamp in, set destination to your local zone, and read the wall-clock minute the user actually clicked. For one-off epoch values, run the seconds through the Unix timestamp converter first.
Confirming overlap windows. You think there is a one-hour overlap between London and Sydney working days, but you want to verify before promising a meeting slot. Convert both endpoints of the overlap and see the exact hours, including the part of the year when only one side has shifted to summer time.
Planning a flight or travel itinerary. A flight departs Frankfurt at 22:15 and lands eleven hours later. Convert the departure to the destination zone, add the duration with the time duration calculator, and you have the wall-clock arrival ready to enter into the calendar.

How it works

The converter glues your date and time into a local ISO string, asks date-fns-tz to interpret it under the source IANA zone, and stores the resulting UTC instant. It then formats that instant under the destination zone using the same library. Because date-fns-tz reads its rules from the IANA tz database, daylight-saving transitions, half-hour zones such as Asia/Kolkata, and 45-minute zones such as Asia/Kathmandu all resolve correctly without any hard-coded offsets.

Pick the source date and time. Enter the calendar date as YYYY-MM-DD and the wall-clock time as HH:MM. The form treats the value as a local clock reading, not a UTC instant.
Choose the source IANA zone. Select the zone the wall-clock time belongs to, such as America/New_York or Europe/Sarajevo. Use a named zone rather than a fixed offset so daylight saving is applied automatically on the right date.
Choose the destination IANA zone. Select where you want to read the same instant. Common choices are UTC, Europe/London, Asia/Tokyo, and Asia/Kolkata, but every zone in the tz database is supported.
Read the converted date, time, and offset. The result shows the destination wall-clock date and time plus the destination offset label, for example +09:00 for Tokyo or Z for UTC. The offset is the one in effect on that exact instant, including any daylight-saving shift.

Worked examples

Standard cross-zone meeting time

Convert 2026-04-27 09:00 in America/New_York to Asia/Tokyo. New York is on EDT (UTC-4) and Tokyo is on JST (UTC+9).

Result: The matching Tokyo wall-clock time is 22:00 on 2026-04-27, with a +09:00 offset label.

Tokyo is 13 hours ahead of New York during US summer time, so a 09:00 New York morning lands at 22:00 Tokyo the same calendar day.

Spring-forward gap in New York

Convert 2026-03-08 02:30 in America/New_York to Europe/London. On that Sunday, New York jumps from 01:59 EST straight to 03:00 EDT, so 02:30 does not exist on local clocks.

Result: The converter still returns a result: 06:30 in Europe/London on the same date.

date-fns-tz resolves the non-existent local time using the post-transition offset (UTC-4), which is why the answer is 06:30 rather than 07:30. London is still on GMT here because UK summer time has not started yet.

Fall-back repeated hour in New York

Convert 2026-11-01 01:30 in America/New_York to UTC. That morning, New York rolls back from 01:59 EDT to 01:00 EST, so 01:30 occurs twice on the local clock.

Result: The converter returns 05:30 UTC for the entered 01:30.

date-fns-tz resolves the ambiguous local time using the earlier (pre-transition) UTC-4 offset, so 01:30 + 4h = 05:30 UTC. To target the second 01:30, pick a unique time such as 02:30 or set a different source zone.

UTC into Tokyo across the date line

Convert 2026-12-31 23:30 in UTC to Asia/Tokyo. Tokyo is nine hours ahead of UTC year-round.

Result: The matching Tokyo time is 08:30 on 2027-01-01, with a +09:00 offset label.

Adding nine hours to 23:30 pushes the wall clock past midnight, so the destination shows the next calendar day. The offset itself does not change because Japan does not observe daylight saving.

Edge cases & gotchas

Daylight-saving spring-forward gaps. On the day clocks spring forward, a 60-minute window of local time never happens. In America/New_York on 2026-03-08, 02:00 through 02:59 is skipped. The converter does not refuse this input; it picks the offset on the post-transition side, so 02:30 resolves the same way as 03:30 would.
Daylight-saving fall-back repeats. When clocks fall back, the same wall-clock hour occurs twice. The converter resolves the ambiguity by using the pre-transition (earlier) offset, which matches the convention used by ECMAScript Date and most server libraries. If you need the second occurrence, enter a time outside the repeated hour or use UTC as the source.
Named zone vs fixed UTC offset. Picking America/New_York is not the same as picking UTC-05:00. The named zone shifts to UTC-04:00 between mid-March and early November because of daylight saving, while the fixed offset never moves. For any date that crosses a DST boundary, always use the named zone so the calc reads the right rule from the tz database.
Date-line crossings change the calendar day. Converting a late-evening or early-morning time can push the result onto the previous or next calendar date. Always read the date field of the result, not just the time, when a conversion crosses 00:00 in either direction. This matters for invoice timestamps, broadcast schedules, and any record dated by local day.

Frequently asked questions about Timezone Converter

What is an IANA timezone?

An IANA zone is a named region in the tz database, such as Europe/Sarajevo or Asia/Kolkata. Each name encodes the full history of UTC offsets and daylight-saving rules for that region, which is why named zones are preferred over fixed offsets like UTC-05:00.

Why does the converter need a date, not just a time?

The UTC offset of a zone changes with the calendar date because of daylight saving and historical rule changes. 09:00 New York is UTC-4 in July and UTC-5 in January, so the calc cannot resolve the conversion without knowing the date.

How does the tool handle the spring-forward hour?

On the morning clocks jump forward, the local hour from 02:00 to 02:59 in America/New_York does not exist. The converter resolves any time entered in that gap using the post-transition offset, which is what date-fns-tz does by default.

How does the tool handle the fall-back hour?

When clocks fall back, the same local hour occurs twice. The converter picks the earlier (pre-transition) offset for ambiguous local times, matching the convention used by ECMAScript Date and most server libraries. To target the second occurrence, switch the source to UTC.

Is the result accurate for past and future dates?

Future conversions are accurate as long as the IANA tz data shipped with the site reflects the current rules. Historical conversions before a country last changed its zone definition use the rule that was in effect on that date, which is what the tz database records.

Can I convert between two zones that are offset by a fraction of an hour?

Yes. Asia/Kolkata is UTC+5:30 and Asia/Kathmandu is UTC+5:45 year-round, and the calc handles both. The destination wall-clock minute may end in :15, :30, or :45 instead of :00.

Why is the offset label sometimes "Z" instead of +00:00?

Z is the single-letter shorthand for UTC offset zero, drawn from the military "Zulu time" naming. RFC 3339 lets parsers treat Z and +00:00 interchangeably, and the converter chooses Z for compactness.

Glossary

IANA tz database: The canonical, community-maintained dataset of every named timezone and its full history of UTC offsets and daylight-saving rules. Used by Linux, macOS, JavaScript, Java, and Python.
UTC offset: The signed difference between a local clock and Coordinated Universal Time, written as +HH:MM or -HH:MM. New York is UTC-5 in winter and UTC-4 in summer.
Daylight saving time: The seasonal shift of local clocks by one hour to extend evening daylight. The shift creates a skipped hour in spring and a repeated hour in autumn.
Spring-forward gap: The 60-minute window of local time that does not occur on the day daylight saving begins, because clocks jump straight from the start to the end of that hour.
Fall-back repeat: The 60-minute window of local time that occurs twice on the day daylight saving ends, because clocks roll back through that hour.
Wall-clock time: The time displayed on a clock in a given location, including any local daylight-saving adjustment. Distinct from a UTC instant, which is offset-free.