How Daylight Saving Breaks Remote Meetings

The weekly sync was anchored to 9am in San Francisco, and for the engineer in Berlin it had been a 6pm call for months. One Monday in March she logged on at 6pm to an empty room. The meeting had ended an hour earlier. Nobody had moved it. The United States had set its clocks forward the day before, and Germany would not do the same for another two weeks, so her 6pm call had quietly become a 5pm one. Two weeks later it changed back, and she nearly missed it again in the other direction.

No one did anything wrong. Everyone was in the same "9am Pacific" meeting they had always been in. The clocks moved underneath them, on different weekends, in different countries, and the fixed point everyone thought they shared turned out to be fixed for exactly one of them.

This is the timezone problem a mental map can't save you from. You can memorize that San Francisco is nine hours behind Berlin and three behind New York, build your whole schedule on those numbers, and be right for most of the year. Twice a year the numbers themselves change, and they don't change everywhere at once. For a few weeks each spring and fall the usual offsets are simply wrong, and the meeting that has run at the same time for six months moves for half the team without anyone touching it.

The changes don't line up

Most people picture daylight saving as one global event, everyone springing forward on the same night. It isn't. The United States moves on the second Sunday of March and the first Sunday of November. The European Union moves on the last Sunday of March and the last Sunday of October. Those dates sit weeks apart, and the gap between them is where the trouble lives.

In March the US springs forward first. For the two or three weeks until the EU catches up, New York and London are four hours apart instead of the usual five. In late October the EU falls back first, and again the gap shrinks to four hours for about a week until the US follows. Your 11am New York call that lands at 4pm in London for most of the year lands at 3pm during those windows. If you scheduled it by anchoring to one city and letting everyone else convert once, the conversion silently goes stale twice a year.

Then there's the half of the world that moves the other way, or doesn't move at all. Australia and New Zealand run daylight saving on the opposite calendar to the northern hemisphere, so their clocks spring forward as ours fall back. Across the year that swings the gap between a US team and a Sydney one by two full hours, and their two changeovers land on their own separate weekends. A large part of the world never changes clocks at all: India, most of Asia and Africa, Arizona. The person in Bangalore does nothing on any of these weekends and still watches their overlap with New York and London slide around them twice a year, because everyone else moved.

The one hour you can least afford to lose

For a team that shares most of a working day, an hour of drift is a nuisance. Someone shows up late once, laughs about it, resets. For a team stretched across a wide gap, the same hour can be the whole relationship.

If your only real overlap with a colleague is a single hour, and daylight saving shifts one end of it, that hour can vanish outright for a couple of weeks. The call you both rearranged your mornings and evenings to protect no longer has two people awake in it. That is the perverse part of the timing. The drift is smallest where you can absorb it and largest, in proportion, exactly where you can't. Teams with a thin overlap window are the ones building their whole week around finding and defending that sliver of shared time, and they're the ones a one-hour shift can knock out completely.

Store the time, don't retype it

The mistake underneath most daylight saving misfires is the same one behind a bare "3pm" dropped into a Slack message: a time got written down as a naked number, cut loose from the zone that gives it meaning. A calendar invite created properly does the right thing on its own. It stores "9am America/Los_Angeles," and every attendee's calendar recomputes the local time on the correct weekend, automatically, for as long as the meeting exists. The software already solved this.

The breakage happens when a human takes the time back out of the software and retypes it somewhere dumber. The 9am becomes "6pm CET" in a shared doc, or "your evening" in a recurring reminder, or a number in someone's head. Now it's frozen. It won't move when the clocks do, and for a few weeks a year it's a lie. The fix is dull and it works: keep times inside tools that understand zones, point people at the calendar entry rather than a copied-out number, and never let a converted time harden into a written constant that can't follow the clock.

Put the transition weeks on the calendar

You can't stop the clocks from changing, so stop letting the changes be surprises. They're on a published schedule years ahead. Mark the four transition weekends on the team calendar the way you'd mark a public holiday, and flag the awkward windows where the US and EU are briefly out of step.

During those weeks, don't schedule anything that can't survive being an hour off. No launch, no first interview with a candidate you're trying to win over, no cross-continent handoff where a missed hour stalls the whole line behind it. Recheck any live meeting that spans the two regions and confirm it still lands where you think. This is the same habit as writing a deadline as a real date and time in one named clock instead of a vague "by Friday": you refuse to let an assumed time stand in for a checked one, especially in the exact stretch when the assumption is likeliest to be wrong.

Don't make the person who didn't move fix it

There's a fairness point buried in here. When the clocks change, the work of noticing falls hardest on the people who changed nothing. The engineer in Bangalore, whose country has held the same offset since 1947, is the one who has to remember that New York moved, London hasn't yet, and the standing call now sits in a different place for three weeks. They did nothing, and they carry the tracking.

So carry it for them. Whoever owns a recurring meeting owns re-confirming it around the transitions and announcing the shift out loud, in each affected person's own local time, before it bites. This is one small, concrete piece of treating timezones as a shared team job instead of a tax each person pays alone. The person most exposed to the change should be the last one expected to track it, not the first.

Daylight saving is a bad deal for distributed teams, and I'll say plainly that it should be abolished. The EU Parliament actually voted to end it in 2019, then let the plan stall, so here we all still are, changing clocks on mismatched weekends for a farming schedule most of us never kept. You can't fix the policy. You can stop pretending the offsets are constant, keep your times in tools that know better, and glance at the calendar in March and October so the clocks never move a meeting you cared about without you seeing it coming.

Let the Clock Changes Sort Themselves Out

Half of surviving daylight saving is making sure a time in a message still means what it meant before the clocks moved. Timely converts every time mentioned in Slack into each person's current local zone automatically, recomputing on the right weekend so nobody does the math, so "let's talk at 4pm London" lands correctly for the New York reader whether it's March, July, or the strange week in between. One less thing to track when the offsets go weird.

Add Timely to Slack — Free · See how it works