How to convert a time between two zones without getting DST wrong

Converting a time between two places sounds like arithmetic, and most of the time it is. You know one city is a certain number of hours ahead of another, you add or subtract, and you are done. The reason people still get it wrong often enough to miss flights and meetings is that the number you are adding is not a property of the two cities. It is a property of the two cities on a particular date, and it moves.

Settle the date first

The single most common mistake is converting a future time using today's difference. If you are arranging a call for late October between London and New York, the gap between them is five hours for most of the year, but for one week at the end of October it is four, because the two sides change their clocks on different dates. Work out the difference for the date of the event, not for the day you happen to be planning it. Our time zone converter asks for a date precisely for this reason, and it is not a formality.

Settle the direction

"Three hours ahead" is ambiguous the moment two people repeat it to each other. Ahead of what? The safe habit is to name both sides in full: "14:00 in Berlin is 08:00 in New York", rather than "Berlin is six hours ahead, so take six off". Writing both readings out also catches the sign error that everyone makes eventually, which is subtracting when you should have added and landing exactly twice the offset away from the right answer.

A useful sanity check is the sun. If your converted time puts a colleague in Sydney on a call at four in the morning, the arithmetic is probably not wrong, but the plan is. If it puts them at four in the afternoon on a date where you expected the middle of the night, the arithmetic almost certainly is.

Check whether either side is on summer time

Roughly a third of the world's countries change their clocks, and those that do are concentrated in Europe, North America and parts of the southern hemisphere, where the seasons run the other way. Two consequences follow. First, the difference between a northern and a southern city can change twice a year in both directions, swinging by two hours in total across the year. Second, the changeover dates do not line up. Europe and the United States both change in spring and autumn, but not on the same weekend, which is where the famous one-week anomalies come from.

You do not need to memorise any of this. You do need to stop treating the difference as a fixed fact about a pair of cities, because that is the assumption that quietly breaks. If you are writing a difference down for someone else, write it in a form that survives the seasons: "UTC+1 in winter and UTC+2 in summer" says something true all year, where "UTC+2" on its own is true for about seven months and misleading for five.

When the place matters more than the zone

Time zones are named after regions, but they are set by governments, and the boundaries follow politics rather than longitude. A country can sit across several natural zones and keep one clock, or share a border with a neighbour an hour apart. This is why it is safer to convert between places than between zone abbreviations. Abbreviations are worse still: IST means Indian Standard Time, Irish Standard Time and Israel Standard Time, three different offsets, and nothing in the letters tells you which one someone meant.

The short version

Pick the date, name both sides in full, and let the tool look up whether either of them is on summer time that day. The arithmetic is the easy part. Knowing which number to use is the part worth being careful about, and it is the part a converter that understands the IANA time zone database will get right for you every time, including in the weeks when the usual answer is temporarily wrong.