Apple time change bug.

> It was 1:15am

But there were two 1:15 a.m.s. How is it supposed to magically know which one you meant? In an ambiguous situation like that, the results would be undefined. I think it’s a valid assumption to just pick the first one, as it sounds like they did.

>Timing is everything.

This isn't about timing. It is about an artifical offset, particular to one part of the world. It's on you to grasp the concept, not on others to cater to your perceptions. The only good solution lies inside your head.

>Bug was filed.

Be sure to add your report #s to your thread for reference, thanks - If you have time, and the response is anything other than 'works as expected', a followup would be informative as well.

Good luck.

The first 1:15 had already passed. It was the second 1:15am and the reminder was trying to be set for the second 1:20am, hence what I would consider a bug. If it had been 11:15pm and a 1:20am reminder had been set, then that would have made sense that there would be no way to determine which one I actually meant.

>no way to determine which one I actually meant

How can NSDate be certain that you meant the first 1:20am and not the second 1:20 am? You agree that had this occured before 1:00 am it 'would have made sense' that you meant the first 1:20am not the second 1:20am - that 'would have made sense' selection of the first occurance of the local time is actually quite arbitrary but is exactly what NSDate is doing. And you believe that because it took place after the first 1:20 am you 'meant' the second 1:20 am. But that presumes that the red indicator is indicating an error not just telling you that the time is in the past. NSDate is chosing to be consistently unique, selecting only the first occurance of the local time and leaving a hole for those who want a reminder during that 1 hour repeated local time.

Have you checked what would happen if you set a reminder during the 'spring forward' hour?