Daylight Saving Time Is Breaking Your Remote Team's Calendar (Here's the Fix)

The broken weeks nobody warns you about

Ask anyone on a distributed team what the difference is between New York and London and they'll answer instantly: five hours. It's the kind of fact that becomes muscle memory after a few months.

It's also wrong for about four weeks a year.

The reason is that the US and the EU don't change their clocks on the same day. The US springs forward on the second Sunday in March. The EU and UK spring forward on the last Sunday in March — up to three weeks later. In autumn the order flips: the EU falls back on the last Sunday in October, the US on the first Sunday in November, a week later.

During those in-between stretches, the gap between New York and London is four hours, not five. Same cities, same teams, different arithmetic — and no notification anywhere telling you it changed.

This is what makes DST such a persistent source of confusion on remote teams. It isn't the clock change itself — everyone knows their own clocks moved. It's that the relationship between two time zones changes without either person's local clock feeling different. Your day looks normal. Their day looks normal. The meeting is still at "9am." And yet somebody is now an hour out.

Why calendar invites don't save you

The standard reassurance is that calendars handle this for you. That's half true, and the half that isn't is where teams get burned.

A calendar invite doesn't store "9am." It stores a moment in time anchored to a specific time zone — usually the organiser's. Every attendee's calendar then renders that moment in their own zone. So the meeting genuinely does happen at one single instant for everybody, and nobody is looking at a stale converted value.

The catch is what that means for a recurring meeting. If your daily standup is anchored to 9:00am in New York, then during those three March weeks it renders as 1:00pm in London instead of the usual 2:00pm. The calendar is behaving exactly as designed. It's just that "correct" here means the meeting moved for everyone outside the anchor zone, and it moved silently.

So the meeting isn't wrong — but it did shift by an hour for half your team, and nobody was told. That's how you get someone joining an empty room at what their calendar told them, or a colleague in Berlin quietly eating an hour of their evening for three weeks. Which brings up the deeper problem:

• The anchor zone never feels the shift. If the organiser is in New York, the meeting is always 9am for them. All the disruption lands on people in other zones — and, predictably, the person who picks the anchor is usually at HQ.
• Everything outside the calendar is still manual. Slack messages, docs, email, "let's sync at 3" — none of that is timezone-aware. Those are plain text, and plain text doesn't spring forward.
• Half-hour and 45-minute zones make it worse. India (UTC+5:30), Nepal (UTC+5:45) and parts of Australia don't sit on neat hour boundaries, so "just add an hour" was never reliable to begin with.

The practical upshot: calendars solve the invite. They don't solve the conversation around the invite, and they don't stop the anchor zone from silently exporting an hour of inconvenience to everyone else.

The 2026–2027 transition calendar

Here are the dates worth putting in your team calendar. The rows in amber are the misaligned stretches — the weeks where your usual offsets don't hold.

Note the asymmetry in the gaps: the spring misalignment lasts two to three weeks, the autumn one only a week. Spring is where most of the damage happens, simply because it drags on long enough for people to stop attributing the weirdness to DST and start assuming the meeting genuinely moved.

The southern hemisphere runs backwards

If your team includes Sydney, Melbourne or Auckland, the picture gets more interesting. Their DST runs on the opposite half of the year — clocks go forward in early October and back in early April.

This means that around the March/April changeovers, the northern and southern hemispheres move in opposite directions at almost the same time. The offset between London and Sydney doesn't shift by one hour — it can shift by two, in the space of a couple of weeks.

Teams spanning both hemispheres are the ones that should be most disciplined about this, because a two-hour swing doesn't just make people late — it can push a meeting clean out of somebody's working day.

And a lot of countries don't do it at all

It's easy to assume DST is universal because it's common in the US and Europe. It isn't. Most of the world's population doesn't change clocks.

• Asia — Japan, China, India, Singapore, South Korea and most of Southeast Asia have no DST at all.
• Mexico — abolished nationwide DST in 2022, keeping it only in some municipalities near the US border.
• Brazil — abolished DST in 2019.
• Most of Africa and the Middle East — no DST, with a handful of exceptions.
• Within the US — Arizona (except the Navajo Nation) and Hawaii don't observe it. Within Australia, Queensland, Western Australia and the Northern Territory don't either.

The consequence is that a team with people in London and Bangalore sees the offset change twice a year even though only one side ever touches their clocks. India stays at UTC+5:30 year-round; London swings between UTC+0 and UTC+1. From Bangalore's perspective, London mysteriously moves an hour twice a year for no local reason at all.

The fix: stop storing offsets in your head

The root cause of every DST bug on a remote team is the same: somebody cached an offset. In a spreadsheet, in a pinned message, in a Slack bio, or just in their memory. Offsets are not constants, so anything that caches one will eventually be wrong.

Three practices fix most of it.

1. Name the zone, not the offset

Write "9am Europe/Madrid," not "9am UTC+1." The first is true all year; the second is true for roughly half of it. This applies to your docs, your onboarding pages, your team directory, and especially any code that touches scheduling — store IANA zone identifiers (America/New_York, Europe/Berlin), never fixed offsets.

2. Rotate your anchor zone, or pick a fair one

Since a recurring meeting has to be anchored somewhere, be deliberate about where. If your team is mostly European with two people in the US, anchoring in a European zone means the DST shift lands on two people instead of ten. And if the split is even, rotate the anchor — the same logic as rotating inconvenient meeting slots.

3. Convert automatically where the conversation happens

Most timezone confusion doesn't happen in a calendar app. It happens in Slack, where someone types "can we push to 3pm?" and four people quietly make four different assumptions. Plain text has no timezone attached, and during a DST gap it's exactly the kind of message that goes wrong.

This is the gap Team TimeZone is built for. Once it's in a channel, it spots times in messages and privately shows each teammate the equivalent in their own zone — using live timezone data, so DST transitions are handled without anyone thinking about it. The original message is untouched; each person just sees their own local time.

The value isn't that it saves a few seconds of arithmetic. It's that it removes the assumption entirely — and assumptions are the thing DST punishes.

A DST checklist for distributed teams

Run through this twice a year, a week or so before the transitions:

1. Put the transition dates on the team calendar. All of them — not just the ones for your own country. An all-day event titled "US clocks change — EU offsets off by 1h until Mar 29" costs nothing and prevents a lot of confusion.
2. Audit recurring meetings that cross the Atlantic. For each one, check what it becomes in every attendee's zone during the gap weeks. If it lands outside someone's working hours, move it for those weeks rather than making them absorb it.
3. Check your anchor zones. Recurring invites created by whoever happened to book the room first tend to be anchored badly. Reassign the ones where the anchor zone is the smallest group.
4. Purge cached offsets. Search your team wiki and pinned messages for things like "UTC+1" or "5 hours behind." Replace them with zone names.
5. Warn the async channels. A single message in your team channel a few days before — "heads up, EU/US offsets are one hour off until the 29th" — heads off most of the individual confusion.
6. Double-check on-call and deploy windows. Anything scheduled by wall-clock time with a handover between regions deserves a look. Coverage gaps caused by DST are much less funny than a missed standup.

Wrapping up

Daylight saving time isn't going anywhere, and no tool can stop the clocks from changing. But nearly all of the pain it causes distributed teams comes from a single avoidable habit: treating the difference between two time zones as a fixed number.

Name your zones instead of your offsets, be deliberate about which zone your recurring meetings are anchored to, and let something automatic do the conversion where your team actually talks. Do that and the March and October transitions become a non-event — which is exactly what they should be.