Past the Date Rollover: The Overlap Window and the Daylight-Saving Drift That Break Global Team Scheduling

A distributed team books a weekly handover call for 8am New York, and for a few months it is perfect: London joins over their afternoon coffee, everyone is awake, the call runs fifteen minutes and the week moves. Then, one week in late October, half of London is missing. Nobody changed the invitation, nobody misread the date, and the call is still at 8am New York. The clocks moved underneath it. That is the failure mode that actually breaks scheduling for a global team, and it is not really a date-rollover problem — it is an overlap problem wearing a rollover's clothing.

Take the rollover as given

The groundwork here is worth having straight before anything else: a calendar date is not a single global instant, and the same day is smeared across two dates once a team spans enough longitude. That mechanic is worked through properly in the companion piece on reading a single day across the world's business hubs, including the worked example of what one UTC-anchored date resolves to in each city and the case for stating a zone rather than saying "end of day." Assume all of that from here on. This post starts one step later, at the question that arrives once you have accepted the rollover: given that a date means different days to different people, when is anybody actually at their desk at the same time as anybody else — and how much does that answer move over the course of a year?

Live overlap is scarcer than almost anyone assumes

Do the arithmetic on the most ordinary transatlantic pairing there is. A standard nine-to-five in London, on summer time, runs from 08:00 to 16:00 UTC. A standard nine-to-five in New York, on eastern daylight time, runs from 13:00 to 21:00 UTC. The intersection is 13:00 to 16:00 UTC — three hours, sitting entirely in London's afternoon and New York's morning. That is the whole live window between the two largest financial centres in the western world: three hours out of an eight-hour day, and one of those hours is lunch for somebody.

Now add Sydney. A Sydney nine-to-five on eastern standard time runs 23:00 to 07:00 UTC. Set that against the London-New York window of 13:00 to 16:00 UTC and the intersection is empty. Not narrow — empty. There is no hour of any day on which London, New York, and Sydney are all inside normal working hours, and no amount of goodwill produces one. The three-way overlap does not shrink toward zero as a figure of speech; it is zero, and the only way to hold a live three-way meeting is for at least one region to work outside its own day. Laying the hubs out side by side with the Timezone Working Hours tool is what makes that concrete: it puts the same moment in all eight cities in front of you, and the empty intersection stops being an abstraction you can argue with.

This is the number that should drive the design of a distributed team, and it is almost never the number people look at. Teams reason about headcount and time zones as if adding a region adds capacity. In overlap terms, adding a distant region subtracts it: every hub you add can only ever intersect the existing window or fail to, never widen it. Two hubs might buy you three shared hours. Three hubs, spread far enough, buy you none.

The window is not even a fixed size

Worse, the overlap you measured is not a constant. Daylight saving does not move the world's clocks together — the northern and southern hemispheres switch in opposite seasons, and even within the north, countries do not switch on the same dates. The consequences are specific and annoying.

• London to New York swings between five hours and four. For most of the year the gap is five. But the United States springs forward in the second week of March while the United Kingdom waits until the end of the month, and the United Kingdom falls back at the end of October while the United States waits until the start of November. In those two gaps the difference is four hours, not five — and the London-New York overlap window is briefly four hours long rather than three.
• London to Sydney swings by two full hours. Sydney springs forward as London falls back, so the gap runs at nine hours during the northern summer and eleven during the northern winter. Nothing intermediate about it: the same pairing is two hours further apart in January than it was in June.
• Half the world does not shift at all. Singapore and Tokyo hold a fixed offset year-round, so their relationship to London and New York changes twice a year purely because of what the other city did.

The practical upshot is that a slot which was comfortable in June can land an hour off in November while the invitation itself is untouched, and near the edges of the working day one hour is enough to push a participant out of their day entirely — or, close to midnight, to flip which calendar date they are on. UTC is the one column in the row that never moves. Everything else slides around it on its own national schedule.

A worked example: the handover call that drifts

Take a London-Sydney handover at 08:00 London, deliberately placed at the very start of London's day because that is the only place a London-Sydney call can live. In June, London is on summer time, so 08:00 London is 07:00 UTC, which is 17:00 in Sydney on standard time — the last hour of Sydney's working day. It is tight, but it works, and both ends are technically at their desks.

Come January, neither team has touched the invitation. London is back on GMT, so 08:00 London is now 08:00 UTC. Sydney is on daylight time, an hour further ahead again. The call now lands at 19:00 in Sydney. The slot did not move; the world moved around it, twice, in the same direction, and a call that was the last hour of the workday is now two hours into someone's evening. Sydney will attend for a while out of politeness, and then attendance will decay, and nobody will connect the decay to a clock change four months earlier.

What scarce overlap forces you to build

Once you accept that live overlap is measured in a handful of hours and sometimes in none, a few things follow that are not really scheduling decisions at all — they are operating-model decisions.

Async-first is not a culture preference, it is arithmetic. If three hubs share zero hours, then any process that requires all three to be live is a process that will not run. The work has to hand off rather than convene: London closes out and writes the state down, New York picks it up, New York closes out and Sydney picks it up. The overlap hours you do have are too expensive to spend on status — they are for the things that genuinely need a conversation, the disagreements and the ambiguous calls, and everything else belongs in writing.

Follow-the-sun is what the gap is good for. The same spread that makes meetings impossible makes elapsed time cheap. Work finished at end of day in one hub lands in the next hub's morning, which means a well-structured handover chain gets close to continuous progress on a single thread. That only works if the handover is deliberate — a written state, a clear next action, a named owner — because the person picking it up cannot ask a question and get an answer for another twelve hours.

The date of an async deadline coordinates the team more than the meeting time does. This is the part teams take longest to internalise. If the live window is three hours a day, then almost all of the coordination is being done by deadlines, not by meetings — and a deadline is a date. "Draft in review by the 14th" does more scheduling work for a distributed team than any recurring call, because it is the thing every hub plans their own local day around. It is also the thing that most needs a zone attached, for the reasons the companion post lays out.

Rotate the pain instead of always exporting it. When a live three-way call is genuinely unavoidable, somebody is working outside their hours, and the default is that the region with the least organisational gravity absorbs it every single time. That is a retention problem disguised as a calendar. The fair version is a rotation: this month the call sits early for Europe, next month it sits late for Asia-Pacific, and the burden is shared rather than assigned. You cannot negotiate that honestly without first knowing exactly how much overlap exists and where it sits, which is the whole reason to measure it rather than guess.

Measure the window before you defend the slot

Almost every argument about a bad meeting time is really an argument about a window nobody has measured. Somebody feels the slot is unfair, somebody else feels it is the only one available, and both are reasoning from their own clock. Put the working hours of every hub on the same axis and the argument resolves itself: either there is a shared window and you can see precisely how wide it is and whose day it sits at the edge of, or there is not, and the honest answer is that the meeting should not exist and the work should be handed off in writing instead. Start by putting a real date through the Timezone Working Hours tool and reading the eight hubs together; then do the overlap arithmetic above against your team's actual hubs, once for June and once for January. Build the schedule around the hours you really have rather than the ones your own calendar makes it easy to imagine.