Why Recurring Events Get the Wrong Alarm Time

Why does a recurring event's alarm fire at the wrong time?

Most of the time, it's a daylight saving transition colliding with how the event's recurrence rule was stored. A weekly 9 a.m. standup that suddenly rings at 10 a.m., or a reminder that's an hour early, almost always traces back to the gap between "floating" local time and a fixed UTC offset baked into the series.

Calendar data uses the iCalendar format (RFC 5545), and a single event can be written three different ways: tied to a named time zone like Europe/Madrid, floating with no offset at all, or pinned to an absolute UTC instant. A weekly meeting written with a named time zone and a weekly recurrence rule stays at the same local time all year, while the same meeting written as a fixed UTC time shifts by an hour once daylight saving starts. The series itself doesn't move — the clock underneath it does, and the app either compensates or it doesn't. This is also why a recurring alarm behaves differently from a recurring event: an alarm is a device-local trigger, while a calendar series is a rule evaluated against a time zone database that changes every year.

What actually breaks during a daylight saving transition?

The recurrence engine keeps the UTC instant of the first occurrence instead of recalculating the wall-clock time for each new offset. One real bug report described a daily 9 a.m. New York event that, after the March transition, kept the series start's UTC instant time rather than its wall-clock time, and the grid drew it in the 10:00 row. The occurrence didn't move in UTC — it moved in the only time zone anyone actually lives in.

This isn't a one-off oddity. A separate calendar plugin logged the identical symptom: during the week of the DST change, all recurring events are automatically shifted by one hour, even though recurring event times should remain fixed according to the local time zone and should not shift due to the DST transition. Exception dates (EXDATE) and overrides inherit the same bug, since EXDATE and recurrence-ID values match the shifted times, so any fix has to move those comparisons too. If you've ever seen a single occurrence in a series "un-cancel" itself after a clock change, this is why — the exception no longer matches the recalculated time.

Why do some calendar apps take a year to fix it?

Because the time zone rule change itself sometimes isn't published until the year it takes effect, and the client has no updated rule to apply in advance. Microsoft documented this directly for Outlook: the issue occurs because Outlook doesn't apply time zone rules for recurring meetings until the year in which the time zone definition change is set to occur.

The clearest example was Brazil suspending daylight saving in 2019. The government announced it would not change clocks for the period running from November 3, 2019 through February 15, 2020, and recurring meetings in that window appeared an hour off in Outlook through the end of 2019 — correcting themselves only once the new year's time zone database loaded. It's the same root cause covered in our calendar reminder wrong time zone guide: the device's time zone database, not the event itself, is usually out of date.

Which calendar platforms handle this correctly?

None of the major calendar platforms are immune, but they fail in different ways and recover on different timelines. Google pushes server-side fixes and documents manual repair steps for affected regions; Outlook depends on the local time zone database shipping before the transition; Apple's iCloud calendar generally applies named time zones correctly but can still display stale times in third-party sync tools that write events without a TZID.

Google even maintains a standing support page for this exact scenario. For the 2026 Canadian transition, Google instructs users to open the next event in the series scheduled after November 1, 2026, and at the top of the event, click "Move one hour earlier" — a manual patch for a problem the server missed. See Google's own Calendar DST fix guide and Microsoft's Outlook time zone troubleshooting doc for the current workarounds on each platform.

How do you fix a recurring event alarm stuck an hour off?

Update the time zone database on the device first, then touch the series itself — both steps matter, because a stale database will keep recalculating the wrong offset even after you edit the event. Confirm the OS is current, open the next upcoming occurrence (not a past one), and apply the time correction to "this and following events" rather than the entire series, which avoids wiping custom guests or attachments on earlier occurrences.

If the series was created from an ICS import or a cross-platform sync tool, check whether the source event carries a named time zone at all. A recurring event with no TZID and no UTC offset is what the spec calls a floating time, and floating time is right for a wake-up alarm that should fire at 09:00 in every office and wrong for almost everything else — including a meeting series meant to stay fixed to one city's clock.

This is exactly the gap Pealo is built to close on iOS: it reads the event directly from Google Calendar, Outlook, or iCloud and converts it into a real AlarmKit alarm that respects the calendar's actual time zone, rather than re-deriving the time from a cached offset. For the deeper mechanics of how that conversion works, see what AlarmKit is and why it matters, and if you're comparing which calendar source handles this best, the Google Calendar alarm setup and Outlook calendar alarm setup pages cover the per-account quirks.