在xls文件中，1900年被计算成了闰年？

前言

2022年，我在某公司负责Java开发时，偶然发现WPS表格存在一个涉及日期计算的系统性Bug。通过邮件向WPS官方反馈后，我深入调查了这一问题的根源。以下是完整的分析过程。

发现过程

开发表格导入功能时，前端解析日期格式单元格（如2023/01/01）会将其转换为数字（代表从1900/1/1起的天数），后端需将此数字还原为日期。
例如：
1代表1900年1月1日
2代表1900年1月2日
3代表1900年1月3日
以此类推。
后端拿到前端发送过来的参数，再将数字转换成对应的日期。

但是，奇怪的问题出现了，我转换后的日期，总是excel传入的日期的后一天。

问题定位

于是开始自测，直觉告诉我，这种差一天的 bug 往往出现在边界，必定是我开发的时候没有注意边界值。
直接试一下边界值测试，于是单元格直接输入1900年1月1日，后端接收到数字是1，转换回日期1900年1月1日。
bug又消失了？！

又随便输了几个日期，1901年1月1日，1902年1月1日，1903年1月1日。
bug竟然又出现了！

于是大胆猜测，1900年1月没有问题，1901年之后又出现了问题，那么bug大概率是在1900年2月28到1900年3月1日之间产生的。

于是在 excel 输入日期
1900年2月28日，后端转换后的日期是1900年2月28日。
1900年2月29日，后端转换后的日期是1900年3月1日。
1900年3月1日，后端转换后的日期是1900年3月2日。

找到bug了，bug是平年闰年的问题！
在wps里面，1900年是闰年，在我的代码里1900年是平年，差值就是1900年2月29日这一天！

结论

“四年一闰，百年不闰，四百年一闰”。这是我们小学二年级就学过的闰年口诀，至今我还记得，难道我记错了？
打开手机，跳转到这个1900年2月，发现并没有29号这个日期。

由此得出结论：1900年是平年，但是 wps 将1900年计算成了闰年！

证据截图

证据1

1.打开WPS在其中一个单元格输入日期格式1900/2/28

2.拉住单元格右下角往右拖动

3.得到不存在的日期1900年2月29日

4.对其他年份也做相同的操作，发现只有1900年存在问题

证据2

选中单元格会看到一个对应的数值，代表从1900年1月1日到现在过了多少天

同样在以下页面也可以看得到

后记

该问题已经普遍存在，包括移动端的表格，以及腾讯在线文档的表格等。如果修复这个bug，会导致修复前后表格显示的日期不一致，所以将错就错，默认了这个bug的存在。
最后，来看看deepseek是怎么说的吧。