Here’s a tip when dealing with UILocalNotifications.
If you want to schedule a notification for a specific time using fireDate
, you need to apply a timeZone
to the UILocalNotification object. Otherwise, iOS will intepret this as an absolute, countdown-based date based on GMT.
To put it another way, suppose you have this code:
You will get a local notification at 8am in your current timezone, just like you would expect. But say you’re in Huntsville (in the Central timezone), and you fly to Utah (in the Mountain time zone). You now get a local notification at 7am. What?
In the AppleDoc for UILocalNotification, we find this:
The date specified in fireDate is interpreted according to the value of this property. If you specify nil (the default), the fire date is interpreted as an absolute GMT time, which is suitable for cases such as countdown timers. If you assign a valid NSTimeZone object to this property, the fire date is interpreted as a wall-clock time that is automatically adjusted when there are changes in time zones; an example suitable for this case is an an alarm clock.
So unless you specify a timezone on your UILocalNotification object, you will get a repeating countdown timer. Which is a little odd from a developer standpoint. This could be implemented a bit more clearly by Apple.
To fix this, you have to apply a timezone to the local notification itself.
According to the docs, this should update automatically if the user’s timezone changes.