How to Convert Time Zones for Remote Meetings (Without Mistakes)

For related fixes and guides, see our troubleshooting hub.

Scheduling a meeting across time zones is one of the most common ways to embarrass yourself professionally. "10 AM your time" sounds clear until you discover one party meant Pacific Standard Time and the other meant Pacific Daylight Time and the meeting now has a one-hour gap.

Here's how to do time zone conversion reliably.

Why Time Zones Are Hard

A few things conspire against you:

Daylight Saving Time shifts twice a year

Most of the US, Europe, and parts of South America observe DST. Most of Asia and Africa don't. The shift happens on different dates in different regions:

• US, Canada: Second Sunday in March (forward), First Sunday in November (back)
• EU, UK: Last Sunday in March (forward), Last Sunday in October (back)
• Australia, NZ: Reverse hemisphere first Sunday in October (forward), first Sunday in April (back)

So during certain weeks (mid-March, late October), the time difference between two cities changes mid-week and any cached "they're 5 hours ahead" calculation is suddenly wrong.

Some zones don't observe DST

Arizona doesn't (except the Navajo Nation). Hawaii doesn't. Most of Saskatchewan doesn't. Most of Asia, Africa, and India doesn't. Brazil dropped DST in 2019.

So "Pacific Time" can mean different actual times depending on whether the location observes DST.

Half-hour and 45-minute offsets exist

India is UTC+5:30. Nepal is UTC+5:45. Adelaide is UTC+9:30. Newfoundland is UTC−3:30. Naive 1-hour-step thinking breaks for these zones.

"Eastern Time" is ambiguous

Without context, "Eastern Time" could mean Eastern Standard Time (EST, UTC−5) or Eastern Daylight Time (EDT, UTC−4). Most people mean "current time in New York" but don't say so.

The Right Way to Reference Times

Three conventions that eliminate confusion:

1. Use IANA time zone names

Instead of "Eastern" or "EST", use America/New_York. The IANA database knows when DST applies and switches automatically.

Standard names you'll use most:

2. Include the UTC offset

"3 PM EST (UTC−5)" leaves no ambiguity. Even if "EST" is misread, the UTC offset is unambiguous.

3. Use UTC for written reference

For status updates, deployment notices, and async messages: state times in UTC. UTC doesn't observe DST and doesn't shift. "Maintenance window: 14:00–16:00 UTC" works for everyone.

The Fast Way: Browser Time Zone Converter

For meeting scheduling, the time zone converter handles all the edge cases:

1. Pick the source zone from the full IANA list
2. Enter date and time
3. Pick the target zone
4. See the converted time, properly handling DST

Daylight saving is handled automatically by the browser's Intl.DateTimeFormat API you don't have to remember which weeks DST is active in which region.

Method 2: World Clock Apps

Many phones, watches, and laptops have a world clock that displays multiple zones simultaneously. Useful for checking "what time is it now?" but tedious for scheduling.

iOS Clock app, macOS Menu Bar Clock, Google Calendar's secondary timezone display, and Outlook's multi-timezone view all work. Set them up once for your most-common collaboration zones.

Method 3: The Calendar Trick

When scheduling a meeting in Google Calendar or Outlook:

1. Create the event in your local time zone
2. The calendar automatically shows it in each invitee's local time when they receive the invite
3. Add the event description with "If this is wrong, your calendar misconfigured your timezone"

This is the safest approach for actual meetings calendars are designed to handle this and rarely get it wrong.

Common Time Zone Mistakes

"Let's meet at 9 PM PST"

Probably wrong. PST (Pacific Standard Time) is UTC−8 and only applies November–March. From March–November, Pacific Time is PDT (UTC−7). Better to say "9 PM Pacific Time" or "9 PM America/Los_Angeles".

Scheduling during the DST shift

The Sunday morning when clocks change is a classic disaster. A 9:00 AM meeting on that Sunday might happen at 8:00 AM, 10:00 AM, or both, depending on how each calendar interpreted it. Avoid scheduling anything between 1 AM and 4 AM on DST shift days.

Using non-standard abbreviations

"CST" means Central Standard Time in the US (UTC−6) but China Standard Time elsewhere (UTC+8). 14 hours of difference. Always use IANA names for international scheduling.

Trusting "right now" times in chat

"Let's chat in an hour" sounds clear when you're typing. By the time the recipient reads it, the "hour" is from when they read it, not when you wrote it. Use absolute times.

When Computers Get It Wrong

Software bugs around time zones are legendary:

• Forgetting to update tzdata. The IANA timezone database changes when countries change their DST rules. Old software has stale data.
• Storing wall-clock time without zone. Storing "2026-03-15 14:00" without a zone means you can't reliably convert it later.
• Daylight saving boundary bugs. Times that "don't exist" (like 2:30 AM during a spring-forward) cause crashes in poorly-written code.

For your own work: store all timestamps in UTC, convert to local time only when displaying. Use the timestamp converter when you need to move between Unix time and human-readable time.

A Meeting Scheduling Workflow

A reliable approach:

1. Pick a candidate time in your local zone
2. Convert to other parties' zones using the time zone converter
3. Check for DST shifts in the next 2 weeks for any of the zones involved
4. Send the invite through a calendar (which handles conversion automatically)
5. Include UTC time in the description as a safety net

Following this process, time zone confusion essentially disappears.

The time zone converter handles the math correctly including DST. For deeper time math (counting business days across zones, scheduling across DST shifts), the date difference calculator and business days calculator help.