Converting time zones without getting it wrong

A client suggests a video call: “Tuesday, 9am Chicago time”. You add six hours, write 3pm in the diary, and when Tuesday comes nobody is online. It was mid-March: the United States had already put its clocks forward, Britain had not. That day the gap was five hours, not six. Almost every time zone mistake looks like this one — the arithmetic is right, it is the assumption behind it that is wrong.

A three-letter abbreviation is not a time zone

Abbreviations are the first source of confusion, because they are neither standardised nor unique:

• CST: Central Standard Time (UTC−6, Chicago), China Standard Time (UTC+8, Beijing) or Cuba Standard Time (UTC−5). Fourteen hours separate the first two.
• IST: India Standard Time (UTC+5:30), Irish Standard Time (UTC+1) or Israel Standard Time (UTC+2).
• BST: British Summer Time (UTC+1) or Bangladesh Standard Time (UTC+6).

The second trap is quieter: PST and EST name the winter time of the American west and east coasts. A webinar advertised as “9:00 AM PST” in July almost always means “9am in Los Angeles”, which is 9:00 PDT. Anyone converting the abbreviation literally joins an hour late.

The only unambiguous label is the IANA zone name: America/Chicago, Asia/Shanghai, Europe/London. It is the vocabulary operating systems, browsers and databases use, and the one to reach for the moment there is any doubt.

Not every offset is a whole number of hours

A good chunk of the planet lives on half-hour offsets, and in a few places quarter-hour ones. Rounding Kathmandu to UTC+6 means missing the first fifteen minutes of a meeting.

Daylight saving, the main cause of error

The calendars do not line up

The United Kingdom and the European Union switch on the last Sunday in March and the last Sunday in October, at 01:00 UTC, at the same instant across all of them. North America switches on the second Sunday in March and the first Sunday in November, at 2am local time — so not at the same instant from one American zone to the next. The result: two windows a year, roughly three weeks in March and a week at the end of October, during which London to New York is four hours instead of five.

The southern hemisphere works the other way round: Sydney goes onto summer time in early October and comes off it in early April. Depending on the date, the London–Sydney gap is nine, ten or eleven hours. No figure worth memorising.

Lastly, plenty of countries no longer change their clocks at all: China (a single zone, UTC+8, for the whole territory), India, Japan, Russia since 2014, Brazil since 2019, most of Mexico since 2022. The gap still moves anyway. Tokyo is nine hours ahead of London in winter and eight in summer — not because Japan changes its clocks, but because Britain does. São Paulo is three hours behind in winter and four in summer, for the same reason.

The hour that does not exist, the hour that happens twice

On the night the clocks go forward in Britain, 01:00 becomes 02:00 outright: between 01:00 and 01:59, no local time exists. An entry of “01:30” on that Sunday corresponds to nothing, and most tools shift it by an hour without saying so. In autumn the reverse happens: 02:00 becomes 01:00 again, the 01:00–01:59 interval occurs twice, and a timestamp with no explicit offset is hopelessly ambiguous.

The time zone converter flags it when the time you enter falls into that spring gap, and says which time it has been adjusted to, instead of shifting it in silence.

The right method: convert an instant, not a time

A local time on its own (“15:00”) means nothing. What exists is an instant: a date, a time and a zone. Hence three habits:

1. Fix the date at the same time as the time — the offset on 20 March is not the offset on 20 April.
2. State the source zone by its zone name, never by an abbreviation.
3. Read every destination at once, instead of adding offsets in your head city by city.

That is exactly how the tool works: you enter a date and a time, choose the source zone, then add as many zones as you need to compare. Each row shows the matching local time and the offset actually in force on that date (UTC+01:00, UTC−04:00, UTC+05:30 and so on). Around thirty zones are offered — the main European, American, Asian, African and Australasian centres, plus UTC — and your own device’s zone is added automatically if it is not among them. A copy button turns the summary into plain text, ready to paste into an invitation. All the arithmetic happens in the browser: nothing is sent anywhere.

Writing the time so it survives being sent

Once the conversion is done, it still has to be passed on without smuggling back the ambiguity you have just removed.

• In a message: give both local times with the cities — “Tuesday 12 May, 9am in Chicago / 3pm in London”. The city name settles everything an abbreviation muddles.
• In a file or an API: ISO 8601 with an explicit offset, 2026-05-12T09:00:00-05:00, or UTC with a Z suffix, 2026-05-12T14:00:00Z.
• For a future or recurring event: store the zone name (Europe/London), not the offset. The rules change, the IANA database that describes them is updated several times a year, and a frozen “+01:00” becomes wrong overnight.

Be wary of am and pm as well: 12:00 am is midnight and 12:00 pm is noon. It is counter-intuitive and it produces appointments twelve hours apart. When in doubt, write 00:00 and 12:00.

What still trips people up, and what to do

UTC, GMT and Z are not synonyms

UTC is a reference; it has no daylight saving, ever. GMT is a time zone: the one the United Kingdom and Ireland keep in winter only, since in summer both are on UTC+1. Labelling a July meeting in London “GMT” is therefore an hour out, and writing “GMT+1” for Paris is right in January and wrong in July. The Z on an ISO timestamp means exactly UTC+00:00.

A duration that straddles a clock change

From 8pm on Saturday to 8pm on Sunday, on the night the clocks go forward, only 23 real hours pass. For counting the calendar days or business days in a contractual deadline, a hire period or a stretch of annual leave, the difference between two dates saves you counting squares on a calendar. For a duration in hours that straddles a switch, though, take the hour off or add it on by hand: that weekend is not 24 hours long.

Logs or exports in timestamps

Server logs, database exports, a great many APIs: these sources use no time zone at all; they count the seconds elapsed since 1 January 1970 at 00:00 UTC. It is the most reliable format there is, and the least readable. The Unix timestamp converter translates it both ways, telling seconds from milliseconds — a value of eleven digits or more is almost always in milliseconds, and reading it as seconds throws the date centuries, even millennia, into the future: a millisecond timestamp from today, thirteen digits long, lands somewhere around the year 58,000.

A “23:59” deadline with no time zone

Calls for papers and academic submissions often use the tag AoE (Anywhere on Earth), which corresponds to UTC−12: the deadline holds as long as there is somewhere on Earth where the date has not turned over. A deadline of “23:59 AoE on 30 June” therefore expires on 1 July at 11:59 UTC, which is 12:59 in London in summer. Half a day of margin that plenty of people let slip because they never work it out.

One rule heads off most incidents: never convert a time without its date and without its zone name, and pass on the two local times rather than an offset. The rest is only arithmetic, so hand it to the tool.