Converter
Runs locallyPopular conversions
Live world clock
Ready. All conversions run in this browser.
What this tool does
Give it a time, tell it which zone that time is expressed in, and it returns the same instant expressed in another zone. That sounds simple, and it would be if every zone were a fixed offset from UTC. The complication is that offsets are not fixed — they change with daylight saving, they change on different dates in different countries, they change by political decision, and in several countries they are not a whole number of hours. Doing the arithmetic by hand is where most scheduling mistakes happen.
This converter resolves the offset for the specific instant you enter, using the IANA time zone database that ships with your browser. If you pick a date in July, it applies the summer rules in force on that date. If you pick a date in December, it applies the winter rules. If you pick 1 March 1995, it applies the rules that were in force then, which may be different from today's. That is why the results are correct across borders and across years, without you needing to know which abbreviation is currently active.
The tool also shows a live clock for thirty cities so you can see current times at a glance, and an offset chip that tells you how far the destination is from the source. Everything runs locally — no request leaves the browser, and there is no geolocation lookup.
How daylight saving is handled
DST is not one rule applied worldwide. Each country sets its own schedule, and even within a country the dates can change over the years. The IANA database records all of it — every offset change for every zone since the 1970s, plus scheduled future changes when they have been announced.
Why the gap between two cities changes twice a year
The US and the EU change on different dates. For most of the year they move in step and the gap between New York and London is five hours. During the transition windows, it is four or six.
| Region | Spring forward | Fall back |
|---|---|---|
| United States | Second Sunday in March | First Sunday in November |
| European Union | Last Sunday in March | Last Sunday in October |
| Australia (southern) | First Sunday in October | First Sunday in April |
| New Zealand | Last Sunday in September | First Sunday in April |
| Iran | Abolished 2022 | — |
The practical effect for New York and London in 2026:
- 8 March – 29 March — US on EDT, UK still on GMT. The gap is 4 hours.
- 29 March – 25 October — both on daylight time. The gap returns to 5 hours.
- 25 October – 1 November — UK back on GMT, US still on EDT. The gap is 4 hours again.
- Rest of the year — both on standard time. The gap is 5 hours.
What about the transition gap itself?
On the day clocks move forward, some wall-clock times do not exist. In New York on 8 March 2026, the clock jumps from 01:59 to 03:00, so "02:30" is a time that never happens. This tool, like most date libraries, rolls such a time forward to the first real instant — 03:30 EDT. On the day clocks move back, some wall-clock times occur twice, and the tool picks the earlier of the two. Both conventions match what your browser does when constructing a Date from wall-clock components, which is the behaviour most developers expect.
Half-hour and quarter-hour zones
Most zones are a whole number of hours from UTC, which makes mental arithmetic easy. Not all of them are. A handful of countries have chosen an offset that matches their solar noon rather than the nearest hour boundary, and the difference matters whenever you convert to or from one of them.
| Zone | Standard offset | Daylight offset | Notes |
|---|---|---|---|
| Asia/Kolkata | UTC+5:30 | — | India — no daylight saving |
| Asia/Kathmandu | UTC+5:45 | — | Nepal — the only quarter-hour offset zone |
| Asia/Colombo | UTC+5:30 | — | Sri Lanka |
| Asia/Tehran | UTC+3:30 | — | Iran — DST abolished in 2022 |
| Asia/Kabul | UTC+4:30 | — | Afghanistan |
| Asia/Yangon | UTC+6:30 | — | Myanmar |
| Australia/Darwin | UTC+9:30 | — | Northern Territory — no DST |
| Australia/Adelaide | UTC+9:30 | UTC+10:30 | South Australia — half-hour shift with DST |
| Pacific/Chatham | UTC+12:45 | UTC+13:45 | New Zealand dependency |
The practical consequence: India is two and a half hours ahead of UTC, not two or three. Dubai is one and a half hours ahead of India, not one or two. When someone in Mumbai says "we'll call at 3 PM" and someone in Dubai opens a calendar tool that assumes whole-hour offsets, the call lands at 1:30 PM Dubai time, and both parties are confused about who was wrong. This converter shows the correct offset and the exact time difference.
Meeting overlap reference
Two time zones overlap for scheduling only when both are inside a normal working day. The window is narrower than most people assume, and it changes with daylight saving. The table below lists the overlap assuming a 9-to-17 working day in both zones and the daylight saving state that applies for most of the year.
| Pair | Overlap window | Note |
|---|---|---|
| New York ↔ London | 09:00–12:00 ET = 14:00–17:00 GMT | US morning, UK afternoon |
| New York ↔ Berlin | 09:00–11:00 ET = 15:00–17:00 CET | Narrower than London because of the extra hour |
| Los Angeles ↔ New York | 09:00–14:00 PT = 12:00–17:00 ET | Five hours, the widest US overlap |
| London ↔ Dubai | 09:00–13:00 GMT = 13:00–17:00 GST | UK morning, Gulf afternoon |
| Karachi ↔ London | 12:00–18:00 PKT = 07:00–13:00 GMT | Pakistan afternoon, UK morning — awkward for both |
| Dubai ↔ Singapore | 12:00–17:00 GST = 16:00–21:00 SGT | Singapore evening overlaps Gulf afternoon |
| Sydney ↔ Los Angeles | — | No working-hours overlap. One side is always out of hours. |
For pairs with no natural overlap, the fairest approach is to alternate the inconvenience: rotate which office gets the early or late call, rather than always favouring the same one. If you must pick a fixed slot, choose the one where the meeting falls just outside working hours rather than in the middle of the night — a 7 AM start is less disruptive than a 2 AM start.
Worked example
Input: 2026-03-20T09:00, From America/New_York, To Europe/London.
The date 20 March 2026 falls inside the transition window — the US has already moved to daylight time, but the EU has not. Let's trace the conversion.
Source zone: America/New_York Source wall clock: 2026-03-20 09:00 Source offset: UTC−4 (EDT — US has been on DST since 8 March) UTC instant: 2026-03-20 13:00 UTC Destination zone: Europe/London Destination offset: UTC+0 (GMT — EU switches on 29 March) Result wall clock: 2026-03-20 13:00 GMT Hourly difference: +4 hours (not the usual +5)
For comparison, running the same conversion on 2026-04-10, after both regions have switched, gives a 5-hour difference: 09:00 EDT → 14:00 BST. The difference changed because the two countries switched on different dates. That is exactly the class of error this tool exists to prevent.
What this converter cannot do
- It cannot predict future political changes. Time zone rules can be amended by governments at short notice. The IANA database is updated when those changes are announced, but if a country abolishes DST mid-year and your browser has not received the update, the conversion will use the old rules until the browser updates.
- It does not distinguish "now" from "in force". A future date is computed using the rules the IANA database expects on that date, not the current rules. If the rules change between now and then, the answer changes with them.
- It cannot tell you where a user is. It does not request geolocation. If you need "my time zone" specifically, select the nearest city from the dropdown.
- It does not handle LMT. Local Mean Time, the pre-standard-era offsets used before time zones were formalised, are technically in the IANA database but predate any practical use of this tool.
- It does not know about daylight-saving exceptions. A few jurisdictions opt out of their region's DST rules — Arizona and Hawaii do not observe US DST, and Saskatchewan is on CST year-round. This tool uses the correct IANA zone for each of those places, but if you select "Phoenix" and assume it follows US rules, you will be an hour off in summer.
- It does not store your history. No conversion you perform is remembered. If you want a log, copy or download the result.
- It does not send calendar invitations. If you need to add a meeting to a calendar, copy the result and create the event in your calendar tool, which will apply the same rules on your device.
Frequently asked questions
Does this handle Daylight Saving Time?
Yes. The converter resolves the offset from the browser's IANA time zone database for the exact instant you select, so PST becomes PDT and GMT becomes BST on the correct dates without any setting. It is equally correct for past dates, including years when US or European DST rules were different.
Can I convert between any two cities?
The dropdown covers more than eighty zones across the Americas, Europe, Africa, the Middle East, South and East Asia, and Oceania, including half-hour and quarter-hour offsets such as India, Nepal, Iran and South Australia. City names are shown for convenience; the underlying identifier is the IANA zone, which is what actually carries the rules.
Is the world clock accurate?
It shows each city's current time using the same IANA database as the converter and your device's clock. It is as accurate as your system clock, which is normally synchronised over the network by your operating system. If your computer's time is wrong, every clock on this page will be wrong in the same way.
Is my location or time data stored?
No. Conversion and clock rendering run in JavaScript on your device. There is no API call and no analytics event containing your time or location. The page requests no geolocation and cannot detect where you are. The only thing stored is your theme choice, in local storage on this device.
What does the Swap button do?
It exchanges the source and destination zones while preserving the exact instant. If you have New York at 10:00 AM converting to London at 3:00 PM, swapping rewrites the input as London 3:00 PM and the output as New York 10:00 AM. The moment in time does not move; only the perspective changes.
How do I convert EST to my local time zone?
Set the source zone to New York, set the destination to the nearest city to you, and enter the date and time. The result updates as you type. If your city is not in the list, pick the nearest entry with the same offset — Lagos for West Africa, Nairobi for East Africa, Karachi for Pakistan, Kolkata for India, and so on.
What is the current time difference between the USA and the UK?
US Eastern Time is normally five hours behind London. Between the second Sunday in March and the last Sunday in March, the gap is four hours, because the US has already moved to daylight time while the UK has not. For those three weeks, and the one week in the autumn when the reverse happens, this converter shows the correct shorter or longer gap automatically.
Why do some zones have half-hour or quarter-hour offsets?
Offsets that are not a whole number of hours are the result of each country defining its own solar noon rather than agreeing on a global grid. India is UTC+5:30, Nepal is UTC+5:45, Iran is UTC+3:30, Myanmar is UTC+6:30, and South Australia is UTC+9:30. These are not errors; they are the official offsets in the IANA database.
Why does the difference between two cities sometimes change by an hour?
Because the two zones switch daylight saving on different dates. The United States changes on the second Sunday in March and the first Sunday in November. The European Union changes on the last Sunday in March and the last Sunday in October. Australia is on the opposite hemisphere and switches in October and April. For the days between those dates, the gap is one hour shorter or longer than usual.
Review us
We're always improving. If the Time Zone Converter has been useful to you, a quick review helps others find it — and helps us know what to build next.
About this tool
Editorial and verification standards are in the editorial policy. Data handling is in the privacy policy.