Flutter_local_notifications: Incorrect time for notification when DST changes

Created on 30 Oct 2018  路  9Comments  路  Source: MaikuB/flutter_local_notifications

Daylight saving times have just changed for us and when this happened all of my notifications have started triggering 1 hour earlier than they should. I'm using the weekly triggers.

It obvious why it happens as the time has changed back 1 hour, but I'm not sure of the best way to resolve it or whether the library should be able to handle this.

help wanted

Most helpful comment

I've got a beta release out with better timezone support that should hopefully resolve the issues with daylight savings. At least it with based on testing I did a spike I did with some native code. May be difficult to get feedback on it but would be much appreciated if you can give it a spin.

All 9 comments

It'd be good if the library can handle however I'm not sure that's possible on Android and would need a way to verify it e.g. https://stackoverflow.com/questions/15361936/alarmmanager-repeating-alarms-and-daylight-saving

There is also a similar issue with time zone changes (e.g., if you set a notification while you're in one time zone, then are in a different time zone when the notification is to fire). I'm not sure this is the same thing, but it seems like it must be. See also #179

I can confirm it's still an issue, we just switched to summer time.
Could you just schedule an alarm for the next upcoming winter/summer time switch and reschedule the alarms then?

@eggenstein I'm not sure if that reply was meant to be directed to me or not and not sure how that is suppose to work. Nevertheless there is definitely an issue with handling DST but as I've mentioned in #179, I'm not sure there is actually a solution that works across multiple platforms. I may need to consider deprecating the existing schedule method and provide one that accepts the time since epoch instead as that's what gets passed to the native OS over the platform channel. If anyone has an idea on a solution that works across both platforms then feel to contribute

Daylight savings time shouldn't be an issue with AlarmManager on Android. I confirmed that my alarms stayed consistent across daylight savings time change in Pacific time zone at least. My test was this:

  • Create a simple app that sets an alarm for March 8, 2020, 3:01am (Pacific).
  • Set the emulator time zone to Pacific, date and time to March 8, 2020, 1:55am
  • Open the app and let the app run until the daylight savings switch occurs naturally (at 2am)
  • The alarm stays set for 3:01am (Pacific) throughout, verified by dumpsys alarm

Time zone changes (and general time changes) will affect alarms though, but you can detect both of these events by registering for the respective Broadcasts and re-scheduling your alarms (assuming you have the proper information to re-schedule them).

Again my statements only apply to Android.

@mikemaksymowych did you set a single alarm or a repeating one? The issue reported here is with related to repeating alarms

Got it, thanks. The issue would be the intervalMillis then, as March 8 2020 only has 23 hours. Seems like an issue on Android then.

I've got a beta release out with better timezone support that should hopefully resolve the issues with daylight savings. At least it with based on testing I did a spike I did with some native code. May be difficult to get feedback on it but would be much appreciated if you can give it a spin.

Changes from beta release are now in the stable 1.5.0 release so will be closing this now

Was this page helpful?
0 / 5 - 0 ratings