Remote Team Time Zones: Scheduling Without Resentment

Overlap windows, rotating meeting pain, and DST traps: how I schedule across New York, London, and Sydney without anyone taking the 3am call every week.

The phrase that starts every scheduling fight

The phrase is: let's do 3pm your time. It sounds considerate, and it fails constantly. The sender has to do the conversion, the receiver assumes the sender did it correctly, and neither writes down which day 3pm lands on for the other person. I have coordinated work spread across New York, London, and Sydney for years, and I can report that most cross-zone scheduling pain is not about geography. It is about sentences that leave the conversion as an exercise for the reader.

My confession up front: the worst offender on my teams was me. I once announced a launch call for 9am without naming a zone, on a team spanning three continents. Three people showed up at three different hours, and the one who joined at 11pm her time was, reasonably, not warm about it. Everything in this post is the system I built after that call, and the system starts with never writing a bare clock time again.

Know your real overlap window, in numbers

Every pair of offices has an overlap window: the hours when both are inside a normal working day. Compute it once and most scheduling debates evaporate. Take August, when New York is on EDT at UTC-4 and London is on BST at UTC+1. A 9-to-5 New York day runs 13:00 to 21:00 UTC; a 9-to-5 London day runs 08:00 to 16:00 UTC. The intersection is 13:00 to 16:00 UTC, which is 9am to noon in New York and 2pm to 5pm in London. Three hours, every workday, without anyone bending.

Now add Sydney, on AEST at UTC+10 in August. A Sydney 9-to-5 runs 23:00 to 07:00 UTC, which intersects the New York day not at all. Zero natural overlap. That is not a scheduling problem to be cleverer about; it is a fact about the planet, and pretending otherwise is how someone ends up owning a permanent 11pm meeting. When I need the actual wall-clock numbers for a specific date, I stop doing offset arithmetic in my head and use a time zone converter, because the offsets themselves move around during the year, as we are about to see.

Rotate the pain, do not assign it

When zero-overlap pairs must meet, the honest options are three: rotate the inconvenient slot, alternate between two fixed slots that each hurt one side, or split the meeting into two regional sessions with shared notes. What corrodes teams is the fourth, unspoken option: the same office eats the 6am or 11pm slot forever because they joined the company later or complain less. Resentment from that compounds quietly and shows up as attrition long after everyone stopped mentioning the meeting time.

The mechanics of rotation matter less than its visibility. Put the rotation in the calendar invite itself, so the fairness is legible: this week Sydney is early, next month New York is late. And schedule fewer synchronous meetings across brutal gaps in the first place; a written weekly update that each office reads at its own 9am does most of what a status call does. I also stopped promising next-day turnarounds across zones, because Friday afternoon in New York is already Saturday morning in Sydney; a business days calculator keeps my delivery promises from quietly landing on someone's weekend.

The DST traps, with 2026 dates

Daylight saving time is where careful schedules go to die, because regions change clocks on different dates and the southern hemisphere moves in the opposite direction. Concretely for 2026: the US springs forward on March 8, but the UK does not until March 29. For those three weeks, New York and London sit 4 hours apart instead of the usual 5, and every standing meeting defined by wall-clock times in both cities silently shifts for one side. The mirror-image window opens in autumn, when London falls back on October 25 and New York holds out until November 1.

Sydney is reversed entirely: it leaves DST on April 5, 2026 and returns on October 4, 2026, so the New York-Sydney gap breathes between 14 hours in northern summer, 16 in northern winter, and 15 in the shoulder weeks when only one of them has switched. Nobody should memorize this; the point of the examples is the opposite. These rules live in the IANA time zone database, they get updated when governments change their minds, and the only sane policy is to let software that tracks that database do the arithmetic, every single time.

Write times so they cannot be misread

The fix for 3pm your time is boring and total: every time you write down includes an explicit zone, and important ones include two renderings. In practice my messages look like: Thursday 15:00 UTC, which is 11am New York, 4pm London. Two extra seconds for the writer, zero ambiguity for every reader, and mistakes become visible because a wrong conversion sits in plain sight next to the UTC anchor.

For anything machines touch, deadlines in configs, cron jobs, token expiries, incident timelines, I go one step further and use the raw Unix timestamp, which has no zone at all and therefore cannot be misread; 1786460400 is 15:00 UTC on August 11, 2026 for every computer on Earth. I keep an epoch timestamp converter open for translating those, and I wrote up how that numbering works in my Unix timestamps explainer. Calendar invites deserve the same paranoia in miniature: create them in your own zone, let the software convert, and never retype a time by hand into a second calendar.

Async first, meetings second

The deepest fix is structural: teams that write well need dramatically fewer synchronous hours, and fewer synchronous hours means the overlap window stops being a battleground. My teams converged on a few practices that consistently pulled meetings out of the calendar.

  • Decisions live in written proposals with a comment deadline stated in UTC, not in meetings
  • Standups are a thread each office posts during its own morning
  • The 3-hour New York-London overlap is protected for real-time work, not consumed by status readouts
  • Recordings plus notes are the default for anything one office had to miss
  • Handoff notes at end of day tell the next zone exactly where things stand, so the sun never idles the project

What I actually changed after the 9am disaster

Three habits, total cost maybe a minute a day. Every written time carries a zone, with UTC as the anchor for anything cross-office. Every recurring cross-zone meeting gets re-checked in the weeks around March, April, October, and November, because those are the 2026 windows where offsets slide. And every brutal time slot is either rotated or replaced with writing, on a schedule everyone can see.

The result is not that scheduling became effortless; the planet still refuses to give New York and Sydney a shared afternoon. The result is that nobody feels ambushed anymore. The unfairness is either eliminated or visibly shared, and the 3am calls that remain were chosen, not inherited. That, in my experience, is the entire difference between a distributed team that hums and one that seethes.

Questions people ask

What is the best meeting time for New York, London, and Sydney together?

There is no slot inside all three working days; New York and Sydney share zero standard business hours. The least-bad options cluster around early morning New York, which is evening in Sydney, and the fair approach is rotating who takes the painful end.

Why did my recurring meeting shift for half the team in March?

The US moved to DST on March 8, 2026 while the UK waited until March 29, so the two cities were temporarily 4 hours apart instead of 5. A wall-clock meeting pinned in one zone moves relative to the other during that window.

Should meetings be scheduled in UTC?

Reference times in UTC in writing, yes, but create calendar events in a real zone and let the calendar convert per attendee. UTC has no DST, so a UTC-pinned event drifts against local clocks twice a year.

How do I stop misreading times in messages?

Adopt one team rule: no bare clock times, ever. Every written time carries a zone, and important ones carry a UTC anchor plus one local rendering, so any conversion error is visible on the page instead of discovered at meeting time.

Read next

All articles
6 min read

What a 70% Chance of Rain Actually Means

Probability of precipitation, decoded: what 70% rain really promises, when highs and lows actually happen, and why day 7 of a forecast keeps changing.