据这名开发者（下用 Peter 代称）介绍，他某日在 Reddit 闲逛时，一个位于 Windows 10 子版块下的帖子引起了他的注意。帖子内容如下：和大家一样，在计算两个日期之间的相隔天数时，Peter 也发现了关于周数的描述明显是错误的，如此大的数值看起来应该是上溢或者下溢之类的问题，要不就是差一错误（off-by-one）等常见的逻辑错误。
本着对这个 bug 的好奇心，再加上 Windows 10 计算器是开源项目，Peter 认为解决这个问题应该不会太复杂，所以他希望亲自找到 bug 并进行修复。
他先在自己的电脑上测试看是否能复现，按照帖子的示例，在测试 7.31-12.31 的间隔天数时，计算器返回的结果是正确的 —— “5个月”。接着 Peter 稍微改了一下日期，改成 7.31-12.30 时，bug 复现了，计算器显示的值为：“5 months, 613566756 weeks, 3 days”，这明显是错误的。
确定了 bug 的存在，Peter 决定从 Windows 计算器的 GitHub 仓库下载源码来研究一番。从 repo 把源码下载到本地后，由于在 IDE 运行 Windows 计算器项目需要 UWP workload，所以 Peter 还为 Visual Studio 添加了 UWP workload。不过 Peter 表示搭建开发环境也十分顺利，修 bug 第一步至此完成。
接着 Peter 打开了解决方案文件（solution file），查看 “Calculator” 项目，并搜索看似相关的任何文件。他找到了界面文件DateCalculator.xaml，接着从相关的文件DateDiff_FromDate追踪到了DateCalculatorViewModel.cpp，最后找到DateCalculator.cpp。
然后 Peter 开始设置断点并观察相关变量的变化，他发现 final 变量DateDifference 的值有误。因此他判断这个 bug 不是由转换为字符串存在错误而导致的，而是实实在在的计算错误。
既然计算存在问题，那就看看它的计算逻辑是如何实现的。
Windows 计算器对间隔日期的计算逻辑用伪代码表示如下：
DateDifference calculate_difference(start_date, end_date) { uint[] diff_types = [year, month, week, day] uint[] typical_days_in_type = [365, 31, 7, 1] uint[] calculated_difference = [0, 0, 0, 0]
date temp_pivot_date
date pivot_date = start_date uint days_diff = calculate_days_difference(start_date, end_date) for(type in differenceTypes) {
temp_pivot_date = pivot_date uint current_guess = days_diff /typicalDaysInType[type]
if(current_guess !=0)
pivot_date = advance_date_by(pivot_date, type, current_guess)
int diff_remaining bool best_guess_hit = false
do{
diff_remaining = calculate_days_difference(pivot_date, end_date) if(diff_remaining < 0) { // pivotDate has gone over the end date; start from the beginning of this unit
current_guess = current_guess - 1
pivot_date = temp_pivot_date
pivot_date = advance_date_by(pivot_date, type, current_guess)
best_guess_hit = true
} else if(diff_remaining > 0) { // pivot_date is still below the end date
if(best_guess_hit) break;
current_guess = current_guess + 1
pivot_date = advance_date_by(pivot_date, type, 1)
}
} while(diff_remaining!=0)
temp_pivot_date = advance_date_by(temp_pivot_date, type, current_guess)
pivot_date = temp_pivot_date
calculated_difference[type] = current_guess
days_diff = calculate_days_difference(pivot_date, end_date)
}
calculcated_difference[day] = days_diff return calculcated_difference
}上面的代码主要做了这些事：先算出相差的年数、然后计算相差的月数、接着计算相差的周数、最后计算相差的天数。
Peter 表示这看起来很正常，他没发现其中的逻辑存在错误。
问题正是在于此，写这段代码的人以为代码会按预料中执行：
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 以进行最小化“修复”。
Peter 为修复加上了引号，是因为它最后计算出的结果如下：
Peter 表示，如果各位认可“7月31日+ 4个月= 11月30日”这样的结果，他认为这在技术上是正确的。虽然完整的结果不符合大众对日期间隔天数的阅读习惯，但至少不会出错。
不过这件事中，最令人深刻的是微软最后合并了 Peter 提交的 PR 以修复这个问题。
这说明微软的开源项目不仅仅是将代码托管在 GitHub 而已，而是会听取来自社区用户的建议和改进。
那么问题来了，如果是你，你会怎样解决这个错误呢？