Time Zone Calculator

Converting a time between zones is simple arithmetic, and that is precisely why it goes wrong so often: the arithmetic is easy, but picking the right offset for the date is not. New York is UTC-5 in winter and UTC-4 in summer, London moves too, and a fixed table cannot know which variant applies to your date. This page gives you both kinds of tool and labels them honestly: a fixed-offset converter for when you already know the offset, and a DST-aware converter, meeting planner and world clock that apply real zone rules for the date you enter.

Quick Answer

How to use each tab

Start with the question you actually have, then pick the tab built for it. The four tabs share one page but answer different questions, and mixing them up is how meetings get missed.

Fixed offset: when you already know the offset

Enter a time, pick a From entry and a To entry from the fixed 29-zone list, and click Convert Time. The tool subtracts the From offset to reach UTC, then adds the To offset, and prints any day shift explicitly, for example (next day, +1) or (previous day, -1). The date field in this tab is a label only: it is printed in the detail line and changes nothing in the arithmetic.

DST-aware: the tab for real scheduling

Pick two real zones, a date and a time, and click Convert. The tool reads each zone’s actual daylight saving rules for that date from the browser’s IANA time zone data, so the offset difference line tells you exactly which offsets applied. This is the tab to use before sending any invite, booking any flight connection, or setting any deadline across zones.

Meeting planner: one time, every participant

Set the meeting in your zone, add up to 6 participants with their zones, and click Plan meeting. The table shows every person’s local time and flags anyone outside 9:00 to 17:00. That window is a rough business-hours starting point, not a rule: it does not know about shift patterns, part-time hours or local holidays, so treat a flag as a prompt to ask, not as a veto.

World clock: one moment, up to 8 zones

Set a reference moment once, add up to 8 zones, and click Show times. It is the fastest way to check a launch, a deadline or a travel day across a team, because every zone is read from the same instant with DST applied for the date.

The DST trap: why fixed lists fail in summer

The trap is not bad arithmetic. It is a correct calculation on the wrong offset. A fixed list must carry standard and daylight variants as separate entries, so the list contains both EST (UTC-5) and EDT (UTC-4) for New York, both WET (UTC+0) and BST (UTC+1) for the London area, and both ACST (UTC+9:30) and ACDT (UTC+10:30) for South Australia. Nothing in the fixed tab stops you choosing the winter entry for a summer date, and nothing warns you afterwards beyond the detail line itself.

Three habits prevent the error. First, for anything that will actually happen, use the DST-aware tab and let the date choose the variant. Second, if you must use the fixed tab, say the variant out loud with the date: July means EDT, not EST; July in London means BST, not the winter entry. Third, re-check any recurring meeting after a clock change, because the gap between two cities can move even when neither meeting time moves.

How the conversion is calculated

Every conversion on this page runs through UTC. The fixed tab computes UTC time as local time minus the From offset, then destination time as UTC time plus the To offset, wrapping past midnight with an explicit day shift. The DST-aware tab does the same calculation, but the offsets come from the IANA time zone database rules for the entered date rather than from a fixed list, which is why its January and July answers for the same city pair can rest on different offsets and still both be right.

Worked fixed example: 23:00 EST (UTC-5) is 04:00 UTC; add JST (UTC+9) and you get 13:00 the next day in Tokyo, an offset difference of +14 hours. Worked DST-aware example: 09:00 in New York on July 15, 2026 is 14:00 in London, and the detail line shows the offsets that produced it (UTC-4 to UTC+1, a +5 hour difference on that date).

The New York to London gap is not what most people think

The common belief is five hours in winter and four in summer. That is wrong for most of the year, and the tool proves it: January 15 gives a +5 hour difference (EST to GMT) and July 15 also gives +5 hours (EDT to BST), because London moves its clocks too. The gap is four hours only in the mismatch weeks, when the United States has already changed its clocks and Europe has not yet, or Europe has already changed back and the United States has not.

United States daylight time in 2026 runs March 8 to November 1, and European daylight time runs March 29 to October 25, according to the federal rule summarised in the references below. Those two different calendars create the mismatch weeks. A recurring meeting set in March or October deserves a re-check in both windows, even if it ran fine all summer.

Half-hour and quarter-hour zones: the list limits you must know

Not every offset is a whole hour, and rounding one is enough to miss a meeting. India runs UTC+5:30 all year with no daylight saving, and it appears in both tabs (IST in the fixed list, Asia/Kolkata in the DST-aware list). South Australia runs UTC+9:30 in winter (ACST) and UTC+10:30 in summer (ACDT), and both entries are in the fixed list. The table below states exactly where each fractional zone can and cannot be selected, because a converter that hides its gaps is worse than one that names them.

For Nepal, the honest workaround is manual: convert through India (UTC+5:30) in either tab, then add 15 minutes to the result. For Adelaide, use the Fixed offset tab with the ACST or ACDT entry that matches your date. These gaps are flagged for the site owner as a possible tool improvement; they are not silently papered over here, because a user who trusts a Sydney result for an Adelaide meeting will be 30 minutes late.

The fixed 29-zone list is a subset, not the world

The Fixed offset tab lists 29 entries. It covers the United States, Canada via the shared United States labels, Western and Central Europe, Moscow, the Gulf, India, South East Asia, China and Singapore, Japan and Korea, Australia and New Zealand, but it contains no African entry at all and only a thin slice of Asia-Pacific. London in winter has no entry labelled GMT in the fixed list; the UTC+0 winter entry is labelled WET (Western Europe Winter), which carries the same offset. The DST-aware tab is broader, with 36 IANA zones including Cairo and Johannesburg, Karachi and Dhaka, and Auckland, but it is still a curated list rather than the full IANA database, and it omits Kathmandu and Adelaide as named above. If your zone is missing from both tabs, convert through UTC or through the nearest zone you can verify, and confirm the result against an authoritative DST-aware source before booking anything unchangeable.

Worked examples you can reproduce in the tool

Every number in this section is the tool’s own output for the inputs shown, so you can re-enter them and confirm. The fixed examples use the fixed tab defaults and entries; the DST-aware examples use the DST-aware tab.

• Fixed, default: 09:00, EST (UTC-5) to the UTC+1 entry (BST) gives 15:00, offset difference +6 hours. Note the default target label is BST, the first UTC+1 entry in the list, not CET.
• Fixed, day rollover: 23:00 EST on 2026-07-15 to JST (UTC+9) gives 13:00 (next day, +1), offset difference +14 hours.
• Fixed, fractional: 09:00 India (UTC+5:30) to EST (UTC-5) gives 22:30 (previous day, -1), offset difference -10.5 hours. The half hour survives the arithmetic exactly.
• DST-aware, summer: 09:00 New York on July 15, 2026 gives Wed 2026-07-15 14:00 (UTC+1) in London, offset difference +5 hours on that date.
• DST-aware, winter: 09:00 New York on January 15, 2026 gives Thu 2026-01-15 14:00 (UTC+0) in London, offset difference +5 hours on that date.
• DST-aware, mismatch week: 09:00 New York on March 20, 2026 gives 13:00 in London (EDT, UTC-4, to GMT, UTC+0), offset difference +4 hours. This is the week the four-hour answer is actually right.
• Meeting planner: 10:00 New York on July 15, 2026 gives 15:00 in London (within 9:00-17:00) and 23:00 in Tokyo (flagged outside 9:00-17:00).
• World clock: 09:00 New York on July 15, 2026 reads 13:00 in UTC, 08:00 in Chicago and 07:00 in Denver in the same table.

When to distrust any converter, including this one

Governments change time zone rules: daylight saving start dates move, and some regions adopt or abolish daylight saving with little notice. The DST-aware tab follows the rules shipped in your browser’s time zone database, so an out-of-date browser or operating system can give an out-of-date answer for a recent rule change. For dates more than a year out, for regions with unstable rules, or for anything unchangeable such as a flight or a contract deadline, confirm against an authoritative DST-aware source before you commit. A converter is a planning aid; it is not a legal record of what a clock showed.

Two related habits help. Read times in 24-hour format when you convert, since 12-hour times invite AM and PM slips on top of zone slips; our military clock calculator covers that conversion. For planning horizons rather than clock times, the hours to days calculator keeps the duration arithmetic separate from the zone arithmetic. And when you announce a converted time to a community, the Discord time calculator formats it so each reader sees their own local time instead of trusting your conversion.

What competing converters get wrong, and what this page does instead

Most single-box converters hide the choice that matters. Some apply one offset all year and never say so, which makes them wrong for half the year in any zone that observes daylight saving. Some bury the date, so a user converts a July meeting with a January offset and never notices. Several meeting planners in the comparison cap free use at two cities, or colour-code overlap without showing the actual local times behind the colours. The gaps that matter most for real scheduling are the ones this page names rather than hides: the fixed list is labelled a subset, the fixed tab’s date is labelled a label, the New York to London gap is corrected to five hours for most of the year, and the Nepal and Adelaide gaps are stated with workarounds instead of being left for users to discover by missing a meeting.

Frequently asked questions

Add This Calculator to Your Website

References