Why Group Alarms Misfire Around Daylight Saving Time: A Technical FAQ

Direct answer: a group alarm fires at the wrong time after a DST transition when the app computed a fixed UTC offset for your alarm and never revisited it, instead of resolving your wake time against the IANA time zone database at the moment the alarm actually fires.

Why does my alarm fire an hour off right after the clocks change?

Most likely cause: the app stored your alarm as “7:00 AM, UTC-5” instead of “7:00 AM, America/New_York.” The offset (UTC-5) is only correct for part of the year. Once daylight saving flips, America/New_York becomes UTC-4, but the cached “-5” sitting in the app’s database doesn’t know that. The alarm fires against stale math, one hour off, until someone edits or resets it — which is why apps like DontSnooze resolve wake time against the named IANA zone rather than a cached offset, every time an alarm reschedules, not just once.

What’s actually the difference between a UTC offset and a named zone?

A UTC offset is a snapshot — a single number valid only until the next transition. A named zone like Europe/London or America/Chicago is a pointer into the IANA tz database’s full rule set: every past and future DST boundary for that region, maintained by volunteers and shipped with the OS. Query a named zone for “what’s the offset right now” and you always get the current answer. Query a cached offset and you get whatever was true when it was cached.

Why would two people in the same group drift apart around DST?

If one member is in a zone that observes DST and the other isn’t, the distance between their local clocks changes on transition weekends and holds until the next one. Arizona (mostly skips DST) and California are the canonical US pair: they’re normally an hour apart, briefly the same clock time for a few weeks in spring, then an hour apart again after fall-back. An app that hardcodes the offset between two users instead of recomputing each person’s wake time independently will get this wrong twice a year, reliably.

Does this only affect apps with a “buddy” or group feature?

No, but it’s easier to spot there. A solo alarm that’s an hour off is annoying; you notice and fix it. A group alarm that’s an hour off means one person’s accountability window closes before the other person’s has even opened, and neither side necessarily notices why. The same class of bug shows up in any scheduling logic that has to stay consistent across multiple devices — DST drift is just the version that’s guaranteed to happen twice a year instead of only on edge cases.

Can this bug happen even if my phone’s clock is correct?

Yes, and this is the part engineers sometimes miss. The OS clock and OS time zone database can be perfectly correct while the app’s own scheduling code still holds a stale cached offset from whenever the alarm was created. The fix isn’t “trust the OS more” — it’s “ask the OS again,” every time, instead of once. A related, more common failure hits at the OS layer rather than the app layer: an overnight version update can reset the permissions an alarm depends on without touching the scheduled time at all, which is a different bug with the same symptom — an alarm that looks armed and isn’t.

What should a well-built alarm app do differently?

Store two things: a wall-clock time (“7:00”) and an IANA zone identifier (“America/Denver”). At every scheduling pass — not just at creation — re-resolve that pair against the current tz rules to get a fresh UTC instant. This is a few extra lines of code against a well-maintained system library, and it’s the difference between an alarm that’s correct forever and one that’s correct until the next transition.