How to Convert Time Zones Without Getting the DST Math Wrong
A time zone converter takes a date and time in one place and tells you the matching date and time somewhere else, accounting for both the raw UTC offset and whichever daylight saving rules apply on that specific date. That second part is where manual conversion falls apart: the gap between two cities isn’t a fixed number you can memorize, because it changes twice a year, and not always on the same day in every country.
Why a fixed offset isn’t enough
Every place on Earth keeps time as an offset from UTC (Coordinated Universal Time), and that part is simple: New York is UTC-5, London is UTC+0, Tokyo is UTC+9. If those offsets never moved, converting between them would just be addition and subtraction.
They do move, though. Around 70 countries observe daylight saving time (DST), shifting their clocks forward by an hour for part of the year and back again later. The official record of who does this, and on which exact dates, lives in the IANA Time Zone Database, the same dataset your phone, your laptop, and this site’s converter below all pull from. A tool built on that database stays correct automatically as the calendar turns. Hand-calculated math like “New York is always 5 hours behind London” doesn’t, and it will eventually bite you.
The trap: the US and Europe don’t flip DST on the same day
Here’s the part most timezone guides skip. The United States and Canada start and end daylight saving on different dates than the EU and UK. In 2026:
- US and Canada: DST runs from Sunday, March 8 to Sunday, November 1.
- EU and UK (“summer time”): DST runs from Sunday, March 29 to Sunday, October 25.
During that three-week window in March, and again for one week in late October, the usual 5-hour gap between the US East Coast and the UK temporarily narrows to 4 hours. Neither country has changed its official offset; the clocks are just out of step with each other for a few weeks.
Worked example: a 9 AM New York call
Say you run a recurring team call fixed to 9:00 AM in New York, with teammates dialing in from London and Tokyo. On an ordinary week (say, any date in January, when nobody involved is mid-DST-transition), here’s how that reads across the three cities:
| City / time zone | Local time | Day offset |
|---|---|---|
| New York (EST, UTC-5) | 9:00 AM | same day |
| London (GMT, UTC+0) | 2:00 PM | same day |
| Tokyo (JST, UTC+9) | 11:00 PM | same day |
Five hours to London, fourteen to Tokyo. Now watch what happens to that exact same 9:00 AM New York slot during the March 8 to March 29 window, once the US has sprung forward to EDT but the UK hasn’t yet moved to BST:
| City / time zone | Local time | Day offset |
|---|---|---|
| New York (EDT, UTC-4) | 9:00 AM | same day |
| London (GMT, UTC+0) | 1:00 PM | same day |
| Tokyo (JST, UTC+9) | 10:00 PM | same day |
Both London and Tokyo shift an hour earlier, not because either city changed anything, but because the meeting is pinned to New York’s local clock, and New York’s UTC offset just moved. A calendar app that recalculates each occurrence from the organizer’s local time handles this correctly without anyone touching a setting. The trouble starts when a person, not the software, is doing the math: if you wrote down “London 2 PM, Tokyo 11 PM” on a sticky note back in January and pasted that same note into a chat message in the third week of March, both times would now be an hour off. The same narrowing happens again for one week, from October 25 to November 1, once Europe has fallen back to GMT but the US is still on EDT for a few more days.
Convert your own times
Pick any two zones and any date below, and the offset (including whether DST applies on that exact day) is calculated for you.
Converted time
Common mistakes
Trusting a memorized offset instead of a specific date. “New York is 5 hours behind London” is true most of the year and wrong for two short windows most people have never heard of. Any offset you memorize only holds outside the March and late-October transition weeks. A date-aware converter beats mental math for exactly that reason.
Treating “GMT” and “UTC” as always interchangeable. They line up for most of the year, but GMT is specifically the UK’s winter time zone name, and once British clocks move to BST in late March, “GMT” stops being the UK’s current time even though people keep saying it out of habit. UTC, by contrast, never shifts for daylight saving; it’s the fixed reference point everything else is measured against.
Assuming every country observes DST. Plenty don’t. Japan has never observed daylight saving time; its clocks sit at a flat UTC+9 all year. That’s why Tokyo’s local time in the tables above only ever moved because New York’s did, not because Tokyo changed anything. Brazil dropped DST nationwide in 2019, and Turkey has held a fixed UTC+3 since 2016. If one leg of your call involves a country like these, that leg’s local time is stable, and any hourly drift you see is coming entirely from the other end.
Copy-pasting a plain-text time instead of a calendar invite. “9am ET” typed into a chat message doesn’t carry any timezone logic with it, so whoever reads it has to do the conversion themselves, on whatever date it happens to be. A proper calendar invite stores the organizer’s zone and recalculates the recipient’s local time automatically, DST included.
Frequently Asked Questions
Why does the same meeting show a different time in London depending on the month?
Because the meeting is scheduled relative to the organizer’s local clock (New York, in the example above), not a frozen UTC timestamp. When New York’s own offset moves for daylight saving, every other city’s derived local time for that same slot shifts along with it, even if that other city hasn’t changed anything on its end.
Does this tool account for daylight saving automatically?
Yes. It reads the IANA time zone database through the browser’s built-in Intl.DateTimeFormat API, so DST rules for the specific date you enter are applied without you needing to look anything up separately.
What does the “+1 day” or “-1 day” indicator mean?
It shows up when the converted time crosses midnight into the previous or next calendar day. A 9:00 PM call in New York, for instance, lands after midnight in most of Europe, so the tool flags that as landing on the following date rather than the same one.
Is there a country whose time zone never changes at all?
Several. Japan has never used daylight saving. Turkey has kept a flat UTC+3 year-round since 2016. Brazil, which used to shift clocks in parts of the country, abolished DST nationwide in 2019. Scheduling with someone in one of these places removes a source of seasonal drift from the conversion entirely.