Free Time Zone Converter — DST-Aware Across 24 Common Zones

What This Calculator Does

This tool answers one practical question: when it is X o’clock on date Y in city A, what time and date is it in city B? You pick a source date, a source clock time in 24-hour format, the source IANA timezone, and the destination IANA timezone. The calculator returns the equivalent wall-clock time in the destination zone, the day-of-week there, and the offset difference (in hours) between the two zones at that exact moment.

The dropdown lists 24 of the most-used IANA timezones — UTC, the four US continental zones plus Alaska and Hawaii, São Paulo and Mexico City for Latin America, the major European hubs (London, Paris, Berlin, Moscow), Cairo and Johannesburg for Africa, the Asian financial centers (Dubai, Karachi, Kolkata, Bangkok, Shanghai, Tokyo, Singapore), and Sydney plus Auckland for Oceania. Every conversion is DST-aware: the underlying engine uses Intl.DateTimeFormat, which reads the IANA tzdata baked into the V8 runtime and applies the correct offset for the actual instant being converted — including the days where one side has shifted clocks and the other has not.

How Time Zone Math Actually Works

Every timezone is just an offset from UTC— the universal time reference anchored at 0° longitude. New York in winter is UTC−5; in summer (Eastern Daylight Time) it is UTC−4. Tokyo is UTC+9 year-round (Japan does not observe DST). Mumbai is UTC+5:30. Kathmandu is UTC+5:45. The conversion math is conceptually simple: take the source wall-clock, subtract the source offset to get UTC, then add the destination offset to get the destination wall-clock.

The trap most by-hand attempts fall into is treating the offset as a constant. New York is “UTC−5” only for about four months of the year — the rest of the time it is UTC−4. London is UTC+0 in winter and UTC+1 (BST) in summer. Most of Australia runs DST in theirsummer (October to April, southern hemisphere), and the rules differ by state. A spreadsheet that hardcodes “NY is 5 hours behind London” will be wrong on roughly half the days of the year.

IANA timezones (like America/New_York or Europe/London) solve this by encoding the full historical and future ruleset for each region — not just the current offset, but every transition date going back decades and the current rule for future ones. The tzdata project ships updates several times a year as governments change their DST policies. That is why this calculator names zones by city, not by abbreviation like “EST” or “CET”: the abbreviations are ambiguous, but the IANA names are precise and stable.

DST and Why It Matters for Conversions

Daylight Saving Time is the single biggest source of bugs in any cross-zone scheduling problem. There are three things to know.

First, DST start and end dates differ by region. The US shifts to daylight time on the second Sunday in March and back on the first Sunday in November. The UK and EU shift on the last Sunday of March and the last Sunday of October. So between mid-March and late March every year, New York and London are only four hours apart instead of the usual five — for about two weeks. After the EU shifts, they go back to five hours apart. The same dance happens in reverse in October and November.

Second, many regions do not observe DST at all. Japan, China, India, most of Africa, Hawaii, Arizona (except the Navajo Nation), and most of South America keep a fixed offset year-round. So if you schedule a recurring weekly meeting between Tokyo and Chicago, the Chicago time changes twice a year while Tokyo does not. Most calendar apps handle this automatically; spreadsheets and hand-built schedules usually do not.

Third, the southern hemisphere is reversed. Sydney enters daylight saving time in October — when New York is leaving it. So the gap between Sydney and New York ranges from 14 hours to 16 hours over the year, depending on which side is currently observing DST.

How to Use This Calculator

1. Pick a source date in YYYY-MM-DD format. This matters: the same clock time on different dates can produce different destination offsets if a DST transition falls in between.
2. Pick a source time in 24-hour format (HH:MM). Use 13:00 for 1 PM, 18:30 for 6:30 PM, 00:00 for midnight at the start of the date you picked.
3. Pick the From timezone — the IANA name of the city or region the source time is local to. If your friend is in Berlin, pick Europe/Berlin, not UTC.
4. Pick the To timezone — the IANA name where you want to know the equivalent local time. The calculator shows the destination wall-clock, the day-of-week there, and the offset difference in hours.

The result line tells you whether you are ahead of or behind the source. A “+9.00h vs source” verdict means the destination is 9 hours ahead — when it is noon at the source, it is 9 PM at the destination. A “−5.00h vs source” verdict means destination is 5 hours behind. If both zones share the same UTC offset on that date, the verdict simply reads “Same offset right now” — useful when you are crossing into UTC equivalents like Reykjavik or one of the West African zones.

Three Worked Examples

Each example below uses a real-world scenario where DST or the international date line creates a subtle pitfall. Try them in the calculator above.

Example 1 — Cross-DST: New York to London on March 10, 2026

You schedule a call from New York for 8:00 AM on March 10, 2026and want to know what time that lands in London. March 10 falls one day after the US has shifted to Eastern Daylight Time (the second Sunday in March was March 8 in 2026), so New York is in EDT — UTC−4. London does not shift until the last Sunday of March (March 29, 2026), so on March 10 London is still on Greenwich Mean Time —UTC+0. The offset difference is 4 hours. So 8:00 AM in New York equals 12:00 PM (noon) in London, same calendar date.

Three weeks later, on April 1, the gap is back to 5 hours because London has joined daylight saving time too. If you reuse the same 8 AM NY slot for a recurring weekly call, your London colleague’s calendar entry needs to drift from 12:00 to 13:00 across that fortnight. This is the most common “why is the recurring meeting off by an hour” question in international teams — and the calculator catches it because the source date determines the offset, not just the source time.

Example 2 — Trans-Pacific midnight wrap: Tokyo to Los Angeles on June 15, 2026

You have a webinar going live at 11:00 PM Tokyo time on June 15, 2026and need to know when Los Angeles attendees will be tuning in. Tokyo runs Japan Standard Time year-round — UTC+9. Los Angeles in mid-June is on Pacific Daylight Time — UTC−7. The offset difference is 16 hours; LA is 16 hours behind Tokyo.

Subtracting 16 hours from 23:00 (11 PM) on June 15 gives 07:00 (7 AM) on June 15. So 11:00 PM Tokyo on June 15 = 7:00 AM Los Angeles on the SAME calendar date, June 15. The two cities share the same date but at very different times of day.

Where the date doeswrap is when you go the other direction. 11:00 PM Los Angeles on June 15 = 3:00 PM Tokyo on June 16 — the next day. The international date line is not a magic wall; the wrap is just a consequence of adding 16 hours to a clock that was already late in the day. The calculator’s output always shows both the date and the day-of-week so you do not have to do this arithmetic yourself, but it pays to understand what is happening: the destination date may move forward or backward from the source date depending on which way the offset shifts you across midnight.

Example 3 — India half-hour offset: Mumbai to Sydney

You are coordinating with someone in Mumbai for a call at 6:30 PM IST and need to know what time that is in Sydney. Mumbai runs Indian Standard Time, which is UTC+5:30— the famous half-hour offset. Sydney in winter (June through September, southern hemisphere winter) runs Australian Eastern Standard Time, UTC+10. The offset difference is exactly 4.5 hours — not 4, not 5. The half-hour is real and matters.

Adding 4.5 hours to 18:30 gives 23:00. So 6:30 PM Mumbai = 11:00 PM Sydney, same calendar date. If you mistakenly round the IST offset to UTC+5, you would land on 10:30 PM Sydney — 30 minutes too early. For a meeting that is fine; for a market order, a flight check-in, or a content publish window, the half hour can be the difference between “on time” and “missed.”

India, Iran (UTC+3:30), Afghanistan (UTC+4:30), Myanmar (UTC+6:30), parts of central Australia (UTC+9:30), Nepal (UTC+5:45), and the Chatham Islands (UTC+12:45) all have non-integer offsets. Any tool that thinks in whole hours will silently mis-handle these zones. IANA-name-based conversion does not.

Common Mistakes

• Hardcoding a single offset between two cities.“NY is 5 hours behind London” is wrong about half the year. Always reconvert for the actual target date when DST transitions are nearby.
• Using ambiguous abbreviations like CST or IST.“CST” can mean Central Standard Time (UTC−6, US), China Standard Time (UTC+8), or Cuban Standard Time. “IST” can mean Indian, Irish, or Israeli. Always pick by city/region using IANA names.
• Rounding a 30- or 45-minute offset to the nearest hour. India, Nepal, Iran, and the Chatham Islands punish this. The half-hour is structural, not a quirk you can ignore.
• Forgetting the destination date may be a different day. 9 PM Sydney is tomorrow morning in California. 11 PM California is tomorrow afternoon in Tokyo. Always copy the day-of-week from the result, not just the time.
• Scheduling recurring meetings without rechecking around DST weeks. March, April, October, and November are the months when EU/US/AU clocks shift on different Sundays. A weekly call that lands at 3 PM Berlin one week may be 2 PM the next week if the calendar app is fighting itself.
• Assuming UTC and GMT are interchangeable. They are functionally the same as a clock reference, but London is noton UTC year-round — it goes to UTC+1 in summer (BST). If you want a stable anchor, pick UTC, notEurope/London.
• Treating “noon” as universal.12:00 in any zone is just a local convention. The actual position of the sun is anywhere from an hour earlier to an hour later than solar noon depending on the zone’s width and DST setting. If you need solar timing (sunrise prayer, photography golden hour), use a sun-position tool, not a timezone calculator.

When This Calculator Decides For You

Time zone conversions are rarely just trivia — the answer usually drives a real scheduling decision. The four most common ones:

1. Cross-team meeting times.Run the proposed slot through both directions: source-to-destination and destination-back. Any slot that lands between 09:00 and 17:00 on both sides is humane; anything outside that on one side will be accepted reluctantly and skipped frequently. The fairer option is to rotate the inconvenience — alternate weeks where one side takes the early call and the other takes the late one.
2. Market hours and trading windows.Tokyo opens at 09:00 JST. London opens at 08:00 BST. New York opens at 09:30 EDT. Plug each into the calculator with your local zone as the destination; the result tells you exactly when each market wakes up in your time. The two-hour overlap between London close and New York open is the most-traded window in global FX — and it is also the window most disrupted by DST drift in March and October.
3. Traveler scheduling.If a flight lands at 06:30 local time in Dubai and you want to know whether to call the office in Chicago to confirm a meeting, run the conversion. 06:30 Dubai equals 21:30 the previous day in Chicago — too late to call. Knowing this before boarding saves the awkward voicemail.
4. Content release timing. A blog post or product launch published at 09:00 New York hits Europe at lunchtime, Asia after work, and Australia in the middle of the night. The calculator lets you pick a launch instant and audit the local experience in every market your audience lives in. If your biggest segment is in Sydney and the result is 03:00 their time, your launch is going to look quiet for eight hours before they wake up.

What This Calculator Doesn’t Handle

A few edge cases require purpose-built tools and are intentionally out of scope:

• The two ambiguous hours of the year— the “fall back” hour where the same wall-clock time happens twice (e.g., 1:30 AM repeats on the day DST ends), and the “spring forward” hour that does not exist (2:30 AM is skipped on the day DST begins). The calculator will give you a defensible answer in both cases, but if your scenario depends on which of the two repeated 1:30s you mean, you need to specify the offset explicitly rather than the wall-clock.
• Historical pre-1970 conversions.Many countries had different offsets and DST rules before the IANA database’s practical floor. The Intl API will extrapolate, but the result is a best-effort approximation, not history.
• Non-Gregorian calendars. The conversion treats all dates as proleptic Gregorian. If your source is a Hijri, Hebrew, or Buddhist calendar date, convert to Gregorian first.
• Solar events.Sunrise, sunset, prayer times, and astronomical twilight depend on latitude, longitude, and altitude — not just timezone. A timezone conversion will not tell you when the sun rises in Reykjavik in December.
• Leap seconds. Civil time in every IANA zone smears or ignores leap seconds; the calculator follows the same convention. For navigation-grade timing you need TAI or GPS time, not local civil time.

For related date math, pair this tool with the age calculator when you need to know exactly how old someone will be on a future date in a different zone, the days-between-dates calculator for spans that cross multiple DST transitions, or the days-until calculatorfor countdowns where the target deadline is anchored to a specific city’s wall-clock rather than UTC.