在飞行模式下或 DST 转换后，NSDate 会向后或向前滑动一小时
我有一个应用程序可以在预定的时间播放警报声。 这被设置为重复警报，每天同时响起。 例如：每天早上6点起床。
我第一次注意到夏令时转换后出现的问题。例如，我会在 12 月创建一个闹钟，让它在每天早上 6 点响起。 3 月后，闹钟提前 1 小时开始响起（或者可能更晚，记不清了）。但是当我尝试调试这个问题时，它永远不会发生，当我坐下来真正深入研究它时，我无法重现这个问题。
最近，当我睡觉时，我一直将手机设置为飞行模式。这似乎更频繁地重现该问题。但有时 一切正常。但是，如果我在进入飞行模式后检查闹钟时间，它们会比我创建的时间晚一个小时。 NSDate 将显示 早上 7 点而不是早上 6 点在我的闹钟表上。但有时会显示为早上 6 点。所以我打开闹钟。但第二天早上 7 点闹钟就响了。
我认为这与夏令时有关，而手机不知道它是否处于夏令时 NSDate 对象。然而，我手机上显示的实际时间从来没有错过。但我的闹钟在错误的时间响起。
这是我的代码示例： 笔记： timeRec 是我的数据库中的结构化记录 AlarmTime 是从数据库中提取的 NSDate 对象 NSLog 值用于调试，看看是否可以打印出错误的结果 但是当我连接到调试器时它从未失败。
NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init] autorelease];
[dateFormatter setTimeStyle:NSDateFormatterMediumStyle];
[dateFormatter setDateStyle:NSDateFormatterMediumStyle];
NSString *tempAlarm = [dateFormatter stringFromDate:timerRec.alarmTime];
NSLog(@"scheduleAlarm for firedate: %@", tempAlarm);
[CCUtility scheduleAlarmForDate: timerRec.alarmTime alarmSound:
[CCUtility convertSoundCodeToFileName: [timerRec.soundCode intValue]]
alarmMessage: message repeatInterval: repeatInterval];
对此的任何帮助将不胜感激。我可以发布额外的代码，但主要问题似乎是我如何使用 NSDate 以及系统时钟如何在飞行模式下在幕后工作。
谢谢，
凯文
I have an application the plays an alarm sound at a scheduled time.
This is setup as a recurring alarm that will go off every day at the same time.
For example: Wake up at 6am every day.
I first noticed a problem after the DST transition. I would have an alarm that I created in December (for example) to go off at 6am every morning. After march the alarm started going off 1 hour earlier (or could have been later, can't remember). But when I tried to debug the problem it would never happen, and by the time I sat down to really dig into it, I couldn't reproduce the problem.
Recently, when I go to bed, I've been putting my phone in airplane mode. This seems to reproduce the problem much more frequently. But there are times when
everything works fine. But if I check the alarm times after I go to airplane mode, they will appear to be an hour later than I created. The NSDate will show
up in my alarm table at 7am instead of 6am. But sometimes it shows up as 6am. So I turn the alarm on. But the next morning the alarm goes off at 7am.
I think it has to do with DST and the phone not knowing if it's in DST for the
NSDate object. However, the actually time shown on my phone has never been wrong. But my alarms go off at the wrong time.
Here is a sample of my code:
Notes:
timerRec is a structured record from my database
alarmTime is a NSDate object pulled from the database
the NSLog value is there for debugging to see if I can get it to print out wrong
But when I'm connected to the debugger it's never failed.
NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init] autorelease];
[dateFormatter setTimeStyle:NSDateFormatterMediumStyle];
[dateFormatter setDateStyle:NSDateFormatterMediumStyle];
NSString *tempAlarm = [dateFormatter stringFromDate:timerRec.alarmTime];
NSLog(@"scheduleAlarm for firedate: %@", tempAlarm);
[CCUtility scheduleAlarmForDate: timerRec.alarmTime alarmSound:
[CCUtility convertSoundCodeToFileName: [timerRec.soundCode intValue]]
alarmMessage: message repeatInterval: repeatInterval];
Any help on this would be greatly appreciated. I can post additional code, but the main problem appears to be something weird about how I'm using NSDate and how the system clock works behind the scenes in airplane mode.
Thanks,
Kevin
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您在存储日期时可能使用不考虑时区的格式。
为什么不直接 NSLog 你的timerRec NSDate 而是使用 NSDateFormatter ？
此外，直接记录 NSDate 将在控制台中显示有关 NSDate 的时区+DST 信息，而您使用的 NSDateFromatterMediumStyle 则不会（使用此日期样式显然并不是调试 TZ 和 TZ 等问题的最佳样式）。夏令时！）
You probably use a format that does not takes the timezone into account when storing your date.
Why don't you NSLog your timerRec NSDate directly instead of using an NSDateFormatter?
In addition, logging the NSDate directly will display the timezone+DST information about the NSDate in the console, whereas the NSDateFromatterMediumStyle you use don't (using this datestyle is obviously really not the best style to use for debugging such issues regading TZ & DST!)