Why Does a Recurring Meeting Move After Daylight Saving Time?

Find the series anchor before changing an hour

A changed local clock reading can be the correct result of a fixed UTC series. A weekly 13:00 UTC meeting appears at 09:00 in New York before its autumn clock change and at 08:00 afterward. A weekly 09:00 New York series instead changes its UTC reading from 13:00 to 14:00 while keeping 09:00 in that zone.

Both are coherent schedules. Which one is right depends on what the organizer intended to keep constant. Do not shift every future entry because the first post-change meeting looks different. First identify the source zone or instant, then compare the recurrence representation and any intentionally changed occurrence.

The two original practice series below have just three occurrences: 25 October, 1 November and 8 November 2026. They avoid the ambiguous overnight transition hour. No meeting was held and no calendar client was imported or tested.

Trace a weekly 09:00 New York series against weekly 13:00 UTC

NIST states that US daylight saving time in 2026 ends on 1 November at 02:00 local time, with the local hour repeated. At 09:00 New York is already on standard time. The equal first row does not make the two recurrence definitions equivalent.

For a Tokyo viewer in this example, the New York-anchored series is 22:00 on 25 October and 23:00 on 1 and 8 November. The UTC-anchored series stays 22:00 for all three. Keeping one city’s clock reading can change another city’s reading; an international schedule needs an explicit organizing zone.

These rows were calculated with Python zoneinfo using tzdata package 2026.3 / IANA 2026c, and checked against a separate dateutil parse of the specimen’s complete 2026 VTIMEZONE. The New York transitions were cross-checked against NIST. IANA’s current page listed 2026f, which was not the package used in this calculation.

Read DTSTART, its zone and RRULE as one definition

The New York practice event has these fields inside a complete VCALENDAR containing its matching timezone definition:

DTSTART;TZID=America/New_York:20261025T090000
DTEND;TZID=America/New_York:20261025T100000
RRULE:FREQ=WEEKLY;COUNT=3

The UTC practice event instead begins at a fixed UTC clock reading:

DTSTART:20261025T130000Z
DTEND:20261025T140000Z
RRULE:FREQ=WEEKLY;COUNT=3

RFC 5545 says DTSTART defines the first recurrence instance. COUNT=3 therefore means three total occurrences, including 25 October, not three additional weeks. Its recurrence discussion recommends a local start with timezone reference when the purpose is to keep the same local time across zone changes.

A bare DTSTART:20261025T090000 is a third meaning: floating 09:00. It is not automatically attached to New York. The floating-time travel comparison explains why that may fit a local routine but can separate people who need one meeting instant.

Download both complete practice series

• Three-occurrence New York 09:00 series
• Three-occurrence UTC 13:00 series

Each file contains one fictional VEVENT with UID, UTC DTSTAMP, start, end and weekly COUNT=3. They have no attendee, organizer, alarm or scheduling METHOD. The timezone-based file includes the March and November 2026 transitions; the UTC file needs no TZID.

The finite VTIMEZONE was built for these 2026 occurrences. RFC 5545 requires a referenced timezone definition to be valid for all instances in the series. Do not turn COUNT=3 into an endless rule while keeping a definition that only describes this window. Real publishers should use appropriate current timezone generation for the whole intended range.

The file checks covered UTF-8, CRLF, physical line lengths, required fields, exclusive end and the three calculated starts. They are not evidence of a specific importer’s behavior. Keep any actual trial separate from your live appointments and note the client/version and result.

Check the organizer, representation and exception separately

1. Ask what should remain fixed. The organizing city’s clock, UTC, or each attendee’s personal local routine?
2. Compare dates on both sides of the change. Record local start, UTC start and exact named zone for a pre-change and post-change occurrence.
3. Inspect the source export. Locate DTSTART, RRULE, TZID or Z, matching VTIMEZONE, and any RDATE/EXDATE or RECURRENCE-ID present.
4. Check whether one occurrence was changed deliberately. A series exception is not automatically a timezone defect. Retain the original recurrence relationship.
5. Check destination and displayed account. Compare the actual imported/subscribed series and viewer settings, not just matching titles on two calendars.
6. Use the supported correction at the source. Preserve existing exceptions and confirm attendee intent before changing the whole series.

If an imported file is only a snapshot, later publisher corrections do not automatically repair it. A subscription has a different update path and may refresh with a delay. Use the existing import-versus-subscription guide before adding another copy.

Keep difficult transition cases and the final check visible

The 09:00 examples avoid the overnight overlap and spring gap. A local time such as 01:30 during an autumn repeat requires the exact occurrence interpretation. RFC 5545 defines a first-occurrence interpretation for an ambiguous explicit DATE-TIME and a pre-gap-offset interpretation for a nonexistent explicit time; its recurrence rules separately say to ignore generated nonexistent local instances. Those cases need their own complete series and rule reading, not an assumed extra hour added to every event.

Timezone policies also differ by place and year. Do not apply New York’s transition date to every zone, or substitute a fixed EST offset for a named zone that has seasonal changes. If a source has stale or missing definitions, keep the precise discrepancy and use the publisher’s supported correction.

A successful diagnosis states the intended anchor, explains every checked occurrence and identifies any unresolved exception. After an actual correction, check a pre-change occurrence, a post-change occurrence and an intentional exception if one exists. Confirm that unrelated timed and all-day DATE entries still have their intended meaning.