Recurring events and daylight-saving changes

A recurring plan creates a finite series of dated occurrences from one selected time. Supported frequencies are daily, weekly and monthly, with an interval and an included occurrence count. The series shares one availability and RSVP response per participant; it does not record a separate attendance answer for every occurrence. Use separate actions when each date needs independent capacity or registration.

Choose the base time and license

Create a dated Plan and select the confirmed or preferred slot if there are several candidates. Choose Repeat, the interval and the total number of occurrences including the first. Recurrence is a paid feature by default, with finite per-series limits. A workspace plan uses its owner’s entitlement rather than an editor’s personal tier. Set the timezone to the actual named location or organizational standard. The displayed local clock time is the anchor for the series. Do not use a fixed numeric offset as if it represented a timezone’s changing daylight-saving rules. A long series should be reviewed near future clock changes.

Follow local time deliberately

For a daily or weekly series, the local date advances while the intended local time remains the same where valid. The UTC time can therefore change when the timezone changes its offset. Participants should read the named timezone and import the dated calendar file instead of assuming a constant offset all year. A local time skipped during a spring transition is invalid and is rejected. A repeated time during an autumn transition needs a clear explicit offset when configuring the base occurrence. If a later generated occurrence is ambiguous or nonexistent, adjust the schedule rather than silently guessing which instant the organizer intended.

Understand month-end behavior

A monthly series preserves the intended day where it exists and clamps to the end of a shorter month. A January 31 base can produce February 28 or 29 and then March 31. This is different from adding a fixed number of days or repeatedly advancing from February’s shortened date. Check the resulting occurrences before sharing. The duration is applied to each dated start, and calendar output uses explicit UTC start and end values. The exported series is a finite set of events, making the actual generated dates visible instead of relying on each calendar application to interpret a rule differently.

Update the real arrangements

A recurring calendar does not reserve a venue every week or renew any payment. Confirm the real host, access requirements, cancellation policy and external bookings separately. If only one occurrence changes, communicate the change clearly; the platform’s shared RSVP is not an attendance ledger for individual dates. After a configuration change, download and review the latest calendar file. Imported files are not a live subscription. Existing calendar entries may need an update or replacement according to the user’s calendar application. Tell participants what changed rather than assuming every calendar silently synchronized.

Continue with related help

• Offer multiple dates and collect availability
• RSVP capacity, guests and the waitlist
• Download and update a calendar file

Search the help center · Current plans and limits · Contact support

Still need a hand?

The site assistant can find related guides. For an account-specific issue, use the support form and include the page URL and exact error, without passwords or payment details.

Contact support ↗