本文讨论了Zune设备在处理2008年闰年时出现的时钟错误，导致设备陷入无限循环的问题。作者强调了在编程中处理边缘案例的重要性，特别是日期和时间相关的计算，因为它们可能导致严重错误。文章提到了其他类似问题，如F-22战斗机的软件错误，以及在处理时区和日期时间时遇到的挑战。作者提醒开发者要重视代码覆盖率和测试，确保代码的正确性。
边缘概率 数学家
免责声明：我不为Zune团队工作，也不认识团队中的任何人。 我认为Z2K9实在是太可惜了，但是我没有任何内在知识。 这里的一切都来自公共互联网。
Dates will get you every time. Further more, it's all about Edge Cases. This is one of the things you'll think about when doing Test Driven Development and it's one of the things that everyone learns in Computer Science 101. You really have to hit those edge cases, be they dates, or number overflows, or buffer overflows.
日期会每次都给您带来帮助。 此外，这全都与Edge Cases有关。 这是您进行测试驱动开发时会考虑的事情之一，也是每个人在计算机科学101中都会学到的事情之一。您确实必须应对那些极端情况，例如日期，数字溢出或缓冲区溢出。
The news reports:
新闻报道：
"A bug in the internal clock driver related to the way the device handles a leap year affected Zune users," said the company in a statement. "That being the case, the issue should be resolved over the next 24 hours as the time change moves to January 1, 2009."
该公司在一份声明中说：“内部时钟驱动程序中的一个错误与该设备处理a年的方式有关，这影响了Zune用户。” “既然如此，随着时间的变化移至2009年1月1日，该问题应在接下来的24小时内解决。”
Disclaimer*2: I have no idea if the following is 100% true, only that it seems quite plausible. I present it for educational purposes, nothing else. It's very interesting. Again, I'm just a caveman.
免责声明* 2：我不知道以下各项是否为100％正确，仅是看起来很合理。 我出于教育目的展示它，仅此而已。 非常有趣再说一次，我只是个穴居人。
A Zune Fan poked around in the source code from the vendor (Freescale Semiconductor) that made the real time clock in the Zune (The vendor's source for rtc.c is here) and with the benefit of hindsight, noted that there's the opportunity to get stuck in an infinite loop.
Zune Fan从供应商(Freescale Semiconductor)的源代码中拨出了代码，该源代码在Zune中制作了实时时钟(此处是rtc.c的供应商源)，事后看来，他指出，有机会获得陷入无限循环。
The Zune 30 shows the date and time, as do many devices, as the number of days and seconds since January 1st, 1980 at midnight.
Zune 30和许多设备一样显示日期和时间，以及自1980年1月1日午夜以来的天数和秒数。
year = ORIGINYEAR; /* = 1980 */
while (days > 365)
{
if (IsLeapYear(year))
{
if (days > 366)
{
days -= 366;
year += 1;
}
}
else
{
days -= 365;
year += 1;
}
}
The days variable is read out of the memory location managed by the Real Time Clock (RTC). When the value of days == 366, you break out of the inner loop, but you can never get out of the outer loop.
从实时时钟(RTC)管理的内存位置中读取days变量。 当days的值== 366时，您会跳出内循环，但永远不会跳出外循环。
A number of folks have blogged about the bug, their analysis and how they'd fix it. Programming Phases has a good post and folks have twittered suggestions). The basic problem is that since there are 366 days remaining when the calculations are reached for the year 2008, there will never be another subtraction to bring the total below 365, so the loop continues. The value of days is stuck at 366. It IS a leap year, but days is not > 366, so the loop continues.
许多人都在博客中发布了有关该错误，他们的分析以及如何修复该错误的信息。 编程阶段有一个不错的帖子，人们对建议进行了推特。 基本的问题是，由于到2008年的计算还有剩余366天的时间，因此永远不会再有减法将总和降低到365以下，因此循环继续进行。 天的值停留在366。这是a年，但天不大于366，因此循环继续。
In working with banking software for years, I can tell you that dates'll get you. When dealing with dates and date math you can't underestimate the value of really good code coverage. Also, even if you have 100% coverage, as I learned in my interview with Quetzal Bradley, 100% coverage just tells you a line of code DID run, it doesn't tell you that it ran correctly.
在使用银行软件多年后，我可以告诉您，日期会帮助您。 在处理日期和日期数学时，您不能低估真正良好的代码覆盖率的价值。 同样，即使您具有100％的覆盖率，正如我在接受Quetzal Bradley采访时了解到的那样， 100％的覆盖率仅告诉您DID运行的代码行，并不能告诉您它运行正确。
I noticed also when I visited my Live home page on Dec-31 that it said today was Jan-1, likely a Time Zone glitch. However, when I clicked the date, I was taken to a page with historical facts about Dec-31. ;)
当我在12月31日访问我的实时首页时，我还注意到今天是1月1日，可能是时区故障。 但是，当我单击日期时，我被带到了一个页面，其中包含有关12月31日的历史事实。 ;)
Dates, especially when TimeZones are added in, are notoriously hard.
众所周知，日期(尤其是添加了TimeZones的日期)很难。
To this day there are a half-dozen bugs in DasBlog where we have a devil of a time with Time Zones. Omar spent weeks fighting with them before he just gave up. We have to reconcile the local time of the visitor, the time on the server, and GMT time (the time we store everything in). It usually works, but when the Server isn't on GMT we get into all sorts of trouble. We also have problems with clients that call the XML-RPC APIs, some of which use UTC (GMT) time and some use local time. Other than keeping an internal table to wrong-headed clients, there are no good solutions.
到目前为止，在DasBlog中有六个错误，在这里我们与时区有一段时光。 奥马尔在放弃之前花了数周与他们作战。 我们必须协调访问者的本地时间，服务器上的时间和GMT时间(将所有内容存储在其中的时间)。 它通常可以正常工作，但是当服务器不在GMT上时，我们会遇到各种各样的麻烦。 调用XML-RPC API的客户端也会遇到问题，其中一些使用UTC(GMT)时间，有些使用本地时间。 除了为错误的客户保留内部表之外，没有其他好的解决方案。
In 2007 CNN talked to a Major General about a bug in some F-22's that caused them to malfunction when going across the international dateline. The Unofficial Apple Weblog had an interesting post on Apple Date/Time bugs through the years. If you're interested in working with and maintaining legacy code, I recommend Michael Feathers' Working Effectively with Legacy Code.
2007年，美国有线电视新闻网(CNN)与少将谈了一些F-22的错误，该错误导致他们在穿越国际日期变更线时发生故障。 非正式的Apple Weblog上有一篇有趣的文章介绍了这些年来的Apple Date / Time错误。 如果您对使用和维护旧代码感兴趣，建议您使用Michael Feathers的《有效使用旧代码》 。
As a random slightly-related aside, I was over at Hollywood Video buying a used copy of Mirror's Edge yesterday and some folks were talking about the Zune problem. The manager said, wow, I'm running the music in here on a Zune right now, and produced his brown 30G Zune from behind the counter. He either hadn't turned it on today fresh or the clock was wrong so he was able to weather the whole day without an incident. He seemed pretty pleased about his "survival."
顺便说一句，我昨天在好莱坞视频公司购买了二手的《镜之边缘》副本，一些人在谈论Zune问题。 经理说，哇，我现在正在Zune上在这里播放音乐，然后从柜台后面制作了棕色的30G Zune。 他要么今天没有打开新的时钟，要么时钟不正确，所以他可以整天不发生任何事故。 他对自己的“生存”感到很高兴。
I wonder how many other less widespread devices are running this real time clock and if any of them had trouble as well.
我想知道还有多少其他较不普及的设备正在运行此实时时钟，以及它们是否也有问题。
Do you have any personal Date/Time stories, Dear Reader? Please share in the comments!
亲爱的读者，您有个人的日期/时间故事吗？ 请分享评论！
翻译自: https://www.hanselman.com/blog/back-to-basics-explore-the-edge-cases-or-date-math-will-get-you
边缘概率 数学家
1338
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
