Keep a Recurring Calendar Meeting at 9 AM Across Daylight Saving Time

If you ask an agent for a weekly 9 AM meeting, the meeting should remain at 9 AM in the named local time zone when the clock changes. Give Google Calendar a recurring event with an IANA timeZone on both start andend. Do not repeat a fixed UTC timestamp every seven days.

A Friday meeting across the March clock change

Consider a hypothetical 30-minute meeting at 9 AM in America/Los_Angeles, starting Friday, March 12, 2027. Its first occurrence is 09:00 with an -08:00 offset. The March 19 occurrence is still 09:00 locally, but its offset is -07:00. In UTC those starts are 17:00 and 16:00 respectively. These are calculated examples, not meetings created in a customer calendar.

{
  "summary": "Friday planning",
  "start": {
    "dateTime": "2027-03-12T09:00:00-08:00",
    "timeZone": "America/Los_Angeles"
  },
  "end": {
    "dateTime": "2027-03-12T09:30:00-08:00",
    "timeZone": "America/Los_Angeles"
  },
  "recurrence": ["RRULE:FREQ=WEEKLY;COUNT=3"]
}

This is the shape accepted by CalendarMCP's create_eventtool. Its implementation passes the start, end, and recurrence rule to Google Calendar's event insertion API. Google's Events resource reference says the time zone is required for recurring events and determines where recurrence is expanded. A numeric offset identifies the first occurrence; it does not by itself describe future local clock changes.

Check the instances before adding attendees

1. Confirm the person's intended local time and IANA zone, rather than interpreting an ambiguous abbreviation.
2. For a real series, first confirm the recurrence rule and end condition. Use the right calendar and its write permission.
3. After creation, call list_events with that calendarId, a date range covering the clock change, and singleEvents: true. It expands the occurrences for inspection.
4. Read each returned start in the intended zone and check the first occurrence after the change. If it moved by an hour, stop before inviting people or editing the series.

The verification step is a recommended workflow, not evidence that a live CalendarMCP series was tested here. Google's recurring events guide describes expanded instances and shows the named zone on both event boundaries. A single event can omit timeZone when its RFC 3339 timestamp carries an offset, but a recurring one needs the expansion zone. CalendarMCP accepts optional timeZonein its input schema; supplying it for a series is the caller's responsibility.

For tool parameters, use the CalendarMCP documentation. The dashboardis the homepage's current setup route if you are ready to connect a calendar.