6 min read

Daylight-saving time and remote meetings

Handle daylight-saving changes in remote meetings with date-aware checks, recurring-invite review, abbreviation risks, and practical steps before sending invites.

When this helps: Use this when recurring meetings or seasonal clock changes could shift one region by an hour. 6 min read Updated 2026-06-14

DST is a scheduling risk, not trivia

Timezone mistakes usually happen when teams memorize offsets and forget that governments can change daylight-saving rules. Date-aware scheduling is safer than mental math because the exact meeting date decides the real local offset.

Recurring meetings need extra care

A recurring invite can appear stable while the local-time impact shifts for one region. Review standing meetings around March, April, October, and November.

Abbreviations are not enough

Use city names or IANA timezones when accuracy matters. EST, CST, and IST can be ambiguous outside a narrow context.

Short transition periods matter

Some regions switch clocks on different weekends. During those gaps, a meeting that was normally one hour apart can move for only one side.

Use location names in invites

Write London, New York, or Los Angeles when people are attending. The calendar can then apply the seasonal offset for the selected date.

Recommended starting point

Review recurring meetings before March, April, October, and November. These months catch many US, UK, and Europe clock-change gaps.

Common failure

The common failure is memorizing an offset and reusing it after the seasonal rule changes.

Use useChrono for the exact date

Use the converter with the exact date first, then verify recurring meetings in the planner after clock changes.

Decision notes

  • Check the first meeting after a clock change, not only the original recurring invite.
  • When an invite spans regions, add both local times to the description so attendees can catch offset changes before joining.
  • If a recurring meeting suddenly feels one hour worse for one region, inspect the timezone field before assuming the calendar is wrong.
  • When a date is mission-critical, verify the result in the calendar system that will send the final invite.
  • If a team uses multiple calendars, test the same invite from the organizer account because display rules can differ by app.
  • When a region does not observe daylight saving, treat that region as the anchor and check the moving region separately.