Time Zone Calculator: How to Schedule Across Time Zones

To schedule across time zones, convert every participant's local time to UTC, compare on that common scale, and then convert back, using each place's offset for that specific date. The offset is the catch: a place's difference from UTC can change during the year when it observes daylight saving time (DST), so the gap between two cities is not always the same number of hours.

How does the conversion work?

Target time = source time - source offset + target offset. A 9:00 AM meeting in New York at UTC-5 is 14:00 UTC (9 - (-5) = 14). In London at UTC+0 that is 2:00 PM, and in India at UTC+5:30 it is 7:30 PM. Add or subtract whole days when the result passes midnight.

Why does the gap between two cities change during the year?

Because cities change their clocks on different dates, or not at all. The table below was computed with the IANA time zone database (release 2026a) built into the Node.js runtime used for this article. It shows what a 9:00 AM Monday meeting in New York is in other cities on five dates in 2026. Rules are set by governments and can change, so confirm important dates against a current source.

Several things show up in the table. New York moved from UTC-5 to UTC-4 on 8 March, while London did not move to UTC+1 until 29 March, so the gap was 4 hours between those dates and 5 hours otherwise. The same happens in autumn: London returned to UTC+0 on 25 October and New York to UTC-5 on 1 November, so 28 October has a 4-hour gap. Kolkata stays at UTC+5:30 all year, so the India gap moves with the other city. Sydney is in the southern hemisphere, so its DST runs the opposite way (UTC+11 in March and November, UTC+10 in April).

How much working-hours overlap do two cities have?

Take 9 AM to 5 PM as working hours in both places and convert both windows to UTC; the overlap is the stretch where they intersect. Using the same arithmetic as the calculator's overlay:

The last rows explain why meetings between the Americas and South Asia usually fall in one side's early morning or the other's evening: a 9:00 AM New York start is 7:30 PM in Kolkata in January (6:30 PM in the weeks when New York is on UTC-4).

Best practices for scheduling

• Write the time with its zone and date: '9:00 AM New York time, Monday 2 March' beats '9:00 AM'. Better still, add the UTC time.
• Use calendar invitations that store the event in a named zone (such as America/New_York) rather than a fixed offset, so the invite follows the clock changes.
• For recurring meetings, re-check the weeks around each clock change, especially March and October to November, when the gap can shift for some pairs of cities but not others.
• Remember zones with half or quarter-hour offsets, such as India (UTC+5:30), Nepal (UTC+5:45) and Newfoundland (UTC-3:30 in standard time). A whole-hour assumption will be wrong for them.
• Watch the date line: when the result crosses midnight, the other participant's date is different. In the table above Sydney sees the Monday meeting as Tuesday morning for part of the year.
• Offer two or three candidate slots and show each in every participant's local time.

Common mistakes

• Using 'EST' year-round. EST is the standard-time name; during DST the name and offset change.
• Assuming everyone changes clocks on the same date or at all. Some places never change, such as Kolkata and Phoenix (which stayed at UTC-7 on every date tested here).
• Doing mental arithmetic across midnight and mixing up the date.
• Trusting a screenshot or old chart of offsets: rules are updated, and a fixed table does not follow them.