我为 Windows 10 修复了一个 bug

问题正是在于此，写这段代码的人以为代码会按预料中执行：

date = advance_date_by(date, month, somenumber) 
date = advance_date_by(date, month, 1) 

逐一运行后如下：

date = advance_date_by(date, month, somenumber + 1)  

常见情况下的确如此。

但问题在于：“如果起始日期为某月的第 31 天，结束日期所在的月份只有 30 天，该以哪天作为结束的标志？”对于 Windows.Globalization.Calendar.AddMonths(Int32) 来说，它的答案显然是“在第 30 天”。

具体而言，这就意味着：

“July 31st + 4 Months = November 30th”
“November 30th + 1 Month = December 30th”

然而实际情况是：

“July 31st + 5 Months = December 31st”

这就引起了“差一错误”。逐步调用Window::Globalization::Calendar::AddMonths会导致GetDifferenceInDays出现负值，然后将其分配给无符号变量daysDiff，经过后面的循环迭代后，daysDiff会将这个负值变为更大的数字。

接着 Peter 在 Windows 计算器的 GitHub 仓库提交了一个 PR 以进行最小化“修复”。

date = advance_date_by(date, month, somenumber + 1)  

Peter 为修复加上了引号，是因为它最后计算出的结果如下：

Peter 表示，如果各位认可“7月31日+ 4个月= 11月30日”这样的结果，他认为这在技术上是正确的。虽然完整的结果不符合大众对日期间隔天数的阅读习惯，但至少不会出错。

不过这件事中，最令人深刻的是微软最后合并了 Peter 提交的 PR 以修复这个问题。

这说明微软的开源项目不仅仅是将代码托管在 GitHub 而已，而是会听取来自社区用户的建议和改进。

那么问题来了，如果是你，你会怎样解决这个错误呢？

【编辑推荐】

1. Slack 进入微软内部禁用服务清单，GitHub 也在其列？
2. 微软禁用GitHub，大水冲了龙皇庙？
3. 开源Windows 10计算器应用迎来Web/Android/iOS移植版
4. 苹果真急了，开始到微软亚马逊家门口挖人了
5. 错失4000亿美金！微软做错了什么？

（编辑：周口站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!