DST mistakes remote teams keep making

The email that starts with "No worries"

I have had the same email from the same freelance client in New York three times. It begins "No worries, I guess something came up?", and it has only ever arrived in March or in the last days of October.

We had a call every Thursday. In the first email thread we agreed on "10:00 your time, 16:00 mine", and then each of us did the reasonable thing and put it in our own calendar. He created a recurring event at 10:00 America/New_York. I created one at 16:00 in my European zone. For most of the year those two events pointed at the same moment, so nobody noticed that we had built two separate clocks.

On the second Sunday of March the US moved its clocks forward. Europe did not, not yet. His 10:00 now landed at 15:00 for me, while my calendar still said 16:00. He sat in the call for ten minutes, wrote the polite email, and went back to work. I opened the link an hour later to an empty room.

The first time, I "fixed" it by moving my own series to 15:00. That was worse. A couple of weeks later Europe moved its clocks too, the gap went back to normal, and now I was the one an hour early. The real fix took thirty seconds: one invite, owned by one person, anchored to one zone, with the UTC time written in the description. I should have done that on day one.

That story contains most of what goes wrong with daylight saving on remote teams. The clocks change on different dates in different places, some places never change at all, and every tool and human brain that stores "my time" instead of a real zone gets quietly wrong for a few weeks.

The dates, stated plainly

It helps to have the actual rules in front of you rather than a vague sense that "the clocks change in spring".

• The EU and the UK change at 01:00 UTC on the last Sunday of March (forward) and the last Sunday of October (back). Every country in that group moves at the same instant, whatever its local time is.
• The United States changes at 02:00 local time on the second Sunday of March (forward) and the first Sunday of November (back). Because it is 02:00 local, the change rolls across the US time zones over several hours.
• Many places do not observe daylight saving at all, including most of Asia, most of Arizona, and Iceland.

The awkward bit is the gap between those dates. In spring the US moves first, and Europe follows two or three weeks later. In autumn Europe moves back first, and the US follows a week later. During those weeks the distance between Europe and the US is one hour shorter than usual.

For this year and next, the dates look like this:

So as I write this, the next mismatch week starts in nine days. If you have a recurring call that crosses the Atlantic, now is the time to look at it.

Mistake one: writing abbreviations instead of zones

"EST", "CET" and "GMT+2" look like zones but behave like guesses. EST strictly means Eastern Standard Time, UTC-5, and plenty of people write it in July when New York is actually on UTC-4. "GMT+2" is correct for part of the year in Central Europe and wrong for the rest. None of these labels carry the information that matters, which is whether the place follows daylight saving rules and which ones.

Diagram

Use IANA zone names instead: America/New_York, Europe/Berlin, Europe/London, America/Phoenix, Atlantic/Reykjavik. Put them in the team roster next to people's names and in any document that mentions a time. Calendar tools handle conversions well when the event's zone field is set properly. Text in a chat message does not convert at all, so a chat message should carry UTC plus the zone name if it carries a time.

Mistake two: two people, two calendars, one meeting

This is my Thursday client call. When two people each create their own recurring event "at the same time", they have actually created two events anchored to two different zones. They agree most of the year and disagree for a few weeks twice a year.

The fix is boring. One person owns the invite. It is anchored to one IANA zone on purpose, and the description says something like "10:00 America/New_York. That is 16:00 in Berlin, except for a few weeks in March and around the end of October, when it is 15:00." When someone asks to move it, the owner moves the one event, rather than everyone editing a private copy.

For freelancers this is worth doing even with a single client. Send the invite yourself, from your calendar, so you know which zone it is anchored to. Then decide whose clock it follows. If the client is paying for "10:00 my time", anchor to their zone and accept that your local time will wobble for a few weeks. Just make the wobble visible instead of finding out from an empty call.

Mistake three: forgetting the places that never change

Teams spread across Europe and the US tend to think of daylight saving as something everyone does. Then someone joins from a place that does not observe it, and the overlap moves without any visible reason.

A developer I worked with in Japan, which does not use daylight saving, had a standing evening slot with our European side. In winter it started at 18:00 for him. When Europe moved its clocks forward in March, the same meeting, still anchored to European time, started at 17:00 for him instead and ate the last hour he usually kept for his own work. He had changed nothing. The map moved around him.

Iceland is a neat example closer to home: it stays on UTC all year, so in winter it shares a clock with London, and in summer it is an hour behind. Most of Arizona stays on Mountain Standard Time all year, so for part of the year it matches Denver and for the rest it matches Los Angeles.

The practical rule is to list people, not countries, in the overlap chart, and to mark which of them shift and which do not. When a shift happens, update the chart, not the person. If a recurring call now lands badly for the person who did not move, that is a scheduling decision for the team, not their problem to absorb quietly.

Mistake four: scheduling jobs in local time

This one is a developer's version of the same bug, and it is mine. On a maintenance retainer for a small business, I wrote a little scheduled export that ran at 02:30 local time on their server. To be precise, I wrote a script that checked every minute whether the local clock said 02:30, which is the kind of thing that feels fine when you write it at 23:00.

On the last Sunday of March, Central European clocks jump from 02:00 straight to 03:00. There is no 02:30 that night. The export did not run, and the client noticed a missing report on Monday morning. In October the opposite happened: clocks go back from 03:00 to 02:00, 02:30 happens twice, and they got two copies of the same report. Neither was a disaster. Both were entirely avoidable.

Real schedulers handle this in different ways. Some run a skipped job late, some skip it, some protect against running twice, and you should not assume you know which without checking. The safer habit is to run servers on UTC and schedule jobs in UTC. If a job genuinely has to follow local business hours, keep it well clear of the small hours between about 01:00 and 04:00 local, which is where the European and US changes happen.

Mistake five: response times and on-call handoffs in local heads

"We reply within one business day" sounds precise until two business days start at different UTC times and the difference changes twice a year. During the mismatch weeks, New York's morning starts an hour earlier on a European clock, and every habit built on "they come online at 15:00" is quietly wrong.

Write response windows and handoffs against UTC, or against one named reference zone that everyone agrees is the official clock for operations. An on-call handoff written as "17:00 local" is two different moments in UTC across the year if the people handing over live under different rules. Put the UTC time in the runbook, and for the weeks around a change, write both the old and new local times next to it.

The same goes for what you promise in writing. If your team has published reply expectations, restate them for the two weeks after a change, because people have memorised the old local times. There is more on wording those promises in async response expectations across time zones.

Mistake six: treating the first missed meeting as carelessness

Someone will miss the first standup after a change. It might be you. The useful response is a single short message with the corrected time in UTC and in each local zone, and a note about when it changes again. Not a pointed comment about calendars.

I've seen a manager make a small joke in the team channel about someone "still on winter time", and it landed badly, because the person was a parent whose shifted standup now collided with the school run. Shaming the first miss makes people quieter. It does nothing to the invite that caused it.

A short runbook for the weeks that hurt

Daylight saving is boring infrastructure, so treat it like infrastructure. Give it an owner who is not the person most punished by the current schedule, and run through the same steps twice a year:

1. Two weeks before the first change (the US in spring, Europe in autumn), list every recurring meeting that crosses the Atlantic or includes someone who does not shift. Check the zone field on each series, not just the friendly time shown in your calendar.
2. Recompute overlap for the mismatch weeks and post it. One line per affected meeting, in UTC with local times beside it.
3. Decide what moves to writing. If a weekly sync only just fits the normal overlap, it will not fit the shortened one. Run it async for those weeks rather than sliding it into someone's dinner.
4. The day after each change, send one message: "Standup stays at 14:00 UTC. From today that is 15:00 in Berlin. New York stays at 10:00 until 1 November, then becomes 09:00." Repeat it at the start of the following week, because people miss the first one.
5. After the second change, ask who missed anything. If a new starter did, your onboarding notes are still describing an offset instead of a zone.

Step three is the one most teams skip, and it is the one I'd argue for hardest. The mismatch weeks are a good excuse to cancel a meeting that has been barely earning its slot. If you are unsure whether it earns it at all, when a remote team needs a meeting is a good filter. The fuller picture of overlap bands, relays and handoffs across several zones is in timezone collaboration without chaos.

The calendar series you created years ago

One last trap, because it bites quietly. A recurring event usually takes its zone from wherever the organiser's laptop thought it was when the series was created. If someone set up the weekly sync while travelling, or while their machine was set to the wrong zone, the series has been anchored to the wrong place ever since. It looks right most of the year, because the wall-clock time matches. It goes wrong in exactly the weeks this post is about.

Once a year, open the details of each important series and read the zone field itself. If it is wrong, fix the series, not just the next occurrence, or you will get to rediscover the same bug next March.

I've come to think of daylight saving as a test that runs twice a year, prepared for or not.

I've come to think of daylight saving as a test that runs twice a year, prepared for or not. Teams that store zones instead of abbreviations, keep one owner per invite and write times in UTC barely notice it. Everyone else spends a fortnight apologising to empty video calls. Of the two, I know which kind of March I prefer.