网络大神：我为win10修复了一个 bug

6月27日消息：日前一位网络大神说：我为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”

然而实际情况是：