Peter为Win10系统修复了一个 bug

据这名开发者（下用 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 计算器对间隔日期的计算逻辑用伪代码表示如下：

DateDifferencecalculate_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] datetemp_pivot_date datepivot_date=start_dateuintdays_diff=calculate_days_difference(start_date,end_date)for(typeindifferenceTypes){ temp_pivot_date=pivot_dateuintcurrent_guess=days_diff/typicalDaysInType[type] if(current_guess!=0) pivot_date=advance_date_by(pivot_date,type,current_guess) intdiff_remainingboolbest_guess_hit=false do{ diff_remaining=calculate_days_difference(pivot_date,end_date)if(diff_remaining<0){//pivotDatehasgoneovertheenddate;startfromthebeginningofthisunit current_guess=current_guess-1 pivot_date=temp_pivot_date pivot_date=advance_date_by(pivot_date,type,current_guess) best_guess_hit=true }elseif(diff_remaining>0){//pivot_dateisstillbelowtheenddate 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_diffreturncalculcated_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 而已，而是会听取来自社区用户的建议和改进。

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