Daylight saving time, explained for remote teams

Daylight saving time (DST) is the practice of moving local clocks forward by an hour in spring and back by an hour in autumn. The intent is to push more daylight into the working evening; the side-effect, for distributed teams, is two annual disruptions when the relative offset between two cities suddenly changes.

Why your meetings move

If you have a recurring meeting between, say, San Francisco and London, and one side switches to or from DST while the other has not yet switched, the gap between the two cities is briefly different from what it was a week ago. For three weeks each spring and one week each autumn, the US-Europe time difference is one hour smaller or larger than usual. Modern calendars handle this automatically as long as your meeting is stored against an IANA identifier — but they cannot handle it if you originally typed in a UTC offset by hand.

This is the single most common cause of "wait, where is everyone?" moments in distributed teams. The fix is structural: always store recurring meeting times in your calendar against the city or IANA zone of one specific person, never against a manually-typed UTC offset. The other side's calendar will automatically render the meeting in their own current local time, even across DST transitions.

Who observes DST

Roughly the northern third of the world, plus parts of the southern hemisphere, observes some form of DST. Most of the European Union shifts on the last Sundays of March and October. Most of the United States and Canada shift on the second Sunday of March and the first Sunday of November. Australia is split: New South Wales, Victoria, the ACT, Tasmania and South Australia observe DST on a different schedule (October to April), while Queensland, the Northern Territory and Western Australia do not observe it at all.

Most of Asia, Africa and South America does not observe DST. China, India, Japan, the Gulf states and most of South-East Asia keep a single offset year-round. This means cross-continental teams can experience strange asymmetries: the gap between London and Singapore changes twice a year (because London moves), but the gap between Tokyo and Singapore is stable.

Practical advice

For each recurring meeting that crosses a DST boundary, mark the four DST transition dates on your team's calendar (US spring, EU spring, US autumn, EU autumn) and, on the Monday after each transition, send a one-line note in your team channel confirming the meeting time in everyone's local zone. Two minutes of work prevents the most common scheduling failure mode in distributed teams.

For one-off meetings within two weeks of a DST transition, double-check the times manually using ZoneShift's converter rather than trusting a half-remembered offset. The converter always shows the offset that is in effect at the moment you load the page, so it is correct on both sides of any transition.