The Remote Worker's Complete Guide to Working Across Time Zones

Working across time zones is one of those things that sounds simple until it isn't. You know your colleague is in Singapore; you know Singapore is ahead of you. You send a meeting invite for 10 AM your time — and then spend the next ten minutes second-guessing yourself about whether you did the maths right.

The maths itself is easy. The problem is that it has more moving parts than most people account for: daylight saving time that shifts offsets twice a year, countries that use half-hour increments, the date line that can make "tomorrow" arrive before "today," and time zone abbreviations that are genuinely ambiguous. Any one of these can turn a confident conversion into a missed call.

What follows are the five rules that, once adopted, remove almost all of that uncertainty.

Rule 1: Always specify a city, never a time zone abbreviation

Time zone abbreviations are unreliable. "EST" can mean Eastern Standard Time (UTC-5) or, if the person typing it didn't know better, Eastern Summer Time in Australia (UTC+11). "IST" is used for Indian Standard Time (UTC+5:30), Irish Standard Time (UTC+1), and Israel Standard Time (UTC+2). "CST" covers Central Standard Time in North America (UTC-6), China Standard Time (UTC+8), and Cuba Standard Time (UTC-5).

A city name is unambiguous. "3 PM New York time" is always 3 PM in America/New_York, whatever offset that happens to be on the day in question. "3 PM EST" is debatable. Every world clock and time zone converter uses IANA city-based identifiers for exactly this reason — they leave no room for misreading.

The habit to build is: when you name a time to a colleague in a different country, always append the city. "Can we do 2 PM London?" rather than "Can we do 2 PM GMT?" It takes three extra words and eliminates one entire category of mistake.

Rule 2: Know your overlap window — and protect it

Almost every cross-timezone team has a window of hours during which all participants' working days overlap. For a London–New York pair, it's roughly 2 PM–6 PM London time (9 AM–1 PM New York). For a London–Mumbai pair, it's tighter: late afternoon London is early evening Mumbai, and mornings overlap better in the other direction. For a London–Tokyo pair, there's almost no overlap in standard working hours at all.

Knowing your actual overlap window is the first step. The second is protecting it: don't use it for internal solo work that could happen at any time, and don't over-schedule it with back-to-back calls that leave no room for the inevitable overrun. When the overlap is only two or three hours, every slot in it is expensive.

A tool like ZoneKit's Meeting Planner shows the overlap visually — a colour-coded strip that makes it immediately obvious which hours are working time, which are early morning, and which are the middle of the night, for each city simultaneously. It recalculates correctly for daylight saving on any date you check.

Rule 3: Anchor async work to the end of your day, not the start

Async communication — messages, documents, recorded updates — works best when timed to land at the start of a colleague's working day rather than the end of yours. If your working day ends at 6 PM London time, that's 2 AM Tokyo time: your colleague won't see your message for another six or seven hours. But if you send it first thing in your morning, it arrives mid-afternoon in Tokyo and can get a response before their day ends.

The pattern that works: write async updates at the beginning of your day, timed to arrive during someone else's working hours, rather than firing off a batch of messages as you close your laptop. For teams with very little overlap, this timing is the primary lever you have on response speed.

Rule 4: Use a date-aware converter during the mismatch weeks

Twice a year, the US and UK/EU change their clocks on different weekends, creating a two-to-three-week window during which the time difference between them is one hour off from what it normally is. If you're using a mental shortcut — "New York is always five hours behind London" — this window will catch you out every year without fail.

A date-aware time zone converter eliminates the problem entirely. Type in the date you're scheduling for, not today's date, and let the converter tell you what the gap is on that specific day. ZoneKit's Time Zone Converter does this: it applies the correct DST offset for the date you enter, so the answer is accurate whether you're in a mismatch week or not.

If you maintain a world clock with your regular cities — like the one on ZoneKit's home page — the current time it shows is always correct. The problem only arises when you're manually projecting forward to a future date and using a fixed offset in your head.

Rule 5: Own the conversion — don't delegate it

When you send a meeting invite or propose a time to a colleague in another country, do the conversion yourself and include both times explicitly. "Does 2 PM London (9 AM New York) work?" is unambiguous and takes two seconds. "Does 2 PM work for you?" puts the conversion burden on the recipient, introduces the risk of their using the wrong offset, and if something goes wrong, you can't tell whether the problem was the time itself or the conversion.

This is especially important when one participant's country is in a mismatch week. If you're not sure, open a converter, enter the specific date, and paste both times into the invite. It costs you thirty seconds and prevents thirty minutes of calendar confusion.

The most common mistakes — and why they happen

Booking in your own local time and trusting the calendar to sort it out. Calendar applications convert times automatically, but only if the event was created with the correct source time zone specified. If you type "2 PM" without a city or offset, your calendar assumes your local time zone — and if your colleague's calendar does the same, you're both looking at 2 PM in your respective time zones, which is exactly the problem you were trying to avoid.

Forgetting that a half-hour offset changes the arithmetic. India (UTC+5:30) and Nepal (UTC+5:45) don't sit on round-hour offsets. Calculating "London is four and a half hours behind Mumbai" requires you to know the half-hour is there; a lot of people default to "five hours" and get every Mumbai call wrong.

Assuming "tomorrow" means the same day for everyone. If you're in New York and it's 10 PM Tuesday, it's already 11 AM Wednesday in Tokyo. A message saying "let's sync tomorrow morning" can reasonably be read as Wednesday morning by you and Thursday morning by your colleague — a full 24-hour slip.

Tools that handle the hard parts automatically

The good news is that all of the above — offset calculations, DST adjustments, half-hour offsets, day changes — are solved problems if you use the right tools rather than mental arithmetic.

• World Clock — shows live current time in all your regular cities, with automatic DST handling. Add the cities once and they're saved. The "Tomorrow" and "Yesterday" labels flag when a city has crossed midnight.
• Meeting Planner — shows the working-hours overlap across multiple cities at once, colour-coded, for any date you choose. The tool for finding meeting slots without back-and-forth.
• Time Zone Converter — converts a specific time on a specific date from one city to another. The tool for verifying a meeting time before you send an invite.
• Countdown Timer — counts down to a fixed moment in time. Shareable link shows the countdown in each recipient's local time zone — useful for deadlines and launches shared across teams.

More ZoneKit guides

• How daylight saving time disrupts remote teams
• GMT vs UTC: what's the difference?
• What is UTC? A plain-English guide
• Time difference between London and New York
• Time difference between London and Mumbai
• Time difference between New York and Tokyo