Time Zone Calculator: Scheduling Calls Without the Guesswork

Most scheduling mistakes are not caused by not knowing the offset. They are caused by assuming the offset never moves. It moves twice a year in both countries, and the two countries do not move on the same weekend.

The offset is a moving target

London and New York are five hours apart for most of the year, whether both are on standard time or both are on summer time. The interesting bit is in between. US clocks spring forward on the second Sunday of March, while UK clocks wait until the last Sunday of March. For those two or three weeks New York is at UTC-4 and London is still at UTC+0, so the gap is four hours, not five.

The same thing happens in reverse in autumn, more briefly. The UK falls back on the last Sunday of October and the US on the first Sunday of November, leaving roughly a week where the gap is again four hours. Three or four weeks a year of half the participants arriving an hour early is a lot of wasted meetings, and it is entirely avoidable by entering the actual date.

A worked three-city call

Take a Monday in January. London is on GMT, UTC+0. New York is on Eastern Standard Time, UTC-5. Sydney is on Australian Eastern Daylight Time, UTC+11, because the southern hemisphere runs its summer time during our winter. A meeting at 14:00 in London is therefore 09:00 in New York and 01:00 the following morning in Sydney.

The date can move too

That Sydney figure is the part people miss. The clock reading is only half the answer; the calendar day changed as well. Book that meeting into a Sydney colleague's Monday and they will miss it, because for them it happens in the small hours of Tuesday. Any decent time zone calculator shows the date alongside the time for exactly this reason.

Half-hour and quarter-hour offsets

Not every zone is a whole number of hours from UTC. India runs at UTC+5:30, so 14:00 in London is 19:30 in Mumbai. Nepal is at UTC+5:45. Newfoundland is at UTC-3:30, and parts of central Australia at UTC+9:30. If you have ever been half an hour late to a call with a colleague in Delhi, that is why.

Using the calculator

Pick cities, not offsets. Choosing "GMT+1" freezes an assumption that will be wrong for half the year, whereas choosing "London" lets the tool apply whichever rule is in force. Set the date as well, since the answer for 20 March and 20 April is genuinely different. Then enter the time on whichever city's clock you are reading, and check whether the output is in 12 or 24 hour format before you write it down. Once you have the slot, our work hours guide and the time calculator walkthrough help with the duration side.

Common questions

Is GMT the same as UTC? Close enough for scheduling, but London is only on GMT in winter. From late March to late October it is on British Summer Time, UTC+1. Writing "10am GMT" in July is ambiguous, and half your recipients will read it as 10am London time anyway.

Why does my calendar invite move on its own? Because it was stored with a zone attached rather than as a fixed clock reading. That is usually correct behaviour: the meeting keeps its real moment when a clock change happens. It only looks wrong when the organiser meant a fixed local time instead.

Is there a good slot for London, New York and Sydney together? Not really. In January, 07:00 in London is 02:00 in New York and 18:00 in Sydney. Someone is always outside working hours, so most teams either rotate the pain or record the call.

Does everywhere in a country change its clocks? No. Arizona stays on Mountain Standard Time all year apart from the Navajo Nation, Hawaii does not change either, and in Australia Queensland and Western Australia stay put while New South Wales and Victoria shift. Selecting the city rather than the state avoids the problem.