代码中的人文故事：从一个Java的“Bug”说起

无意间看到思否里面的一篇文章，果断的转载， 代码中的人文故事：从一个Java的“Bug”说起

缘起

这几日闲来无事撸代码，无意中发现一桩趣事。原以为是一个Java的bug，没想到经过一系列死磕，挖掘出了一段和中国历史乃至人类文明相关联的人文故事，不禁唏嘘感叹一番。

这件事的缘起很简单，我在实现计算两个日期天数距离逻辑的过程中，发现了一个很诡异的事情，同样的起始日期，用python和Java计算出的结果居然不一样！

例如，计算一个1990年1月1日到1990年9月4日之间的天数，用python计算如图：
得出天数为246。可以看到，python的API设计简单。
WTF!?得出的天数居然是245天？为什么和Python算出来的不一样？我马上实际数了一下，应该是246天，Python算的结果是对的！
仔细核对了程序实现，没毛病啊？难道有精读损失？

狐疑（懵逼）

进而加入如下输出：
什么鬼？这0.0416666667天跑哪里去了？需知：
也就是说，Java计算的时间和实际正好差了一个小时！

无独有偶，各种百度后，居然发现了和我有类似疑问的兄弟：
然而这个提问下并没有靠谱的答案！
这样看，似乎很像时区上出了问题，然而并不是，前后Calendar对象的时区完全一致！都是Asia/Shanghai！
由此难免要想，难道Java代码有Bug？把这一个小时给吃了？好吃吗？啥味道？
然而，用同样的函数，计算990年1月1日到1990年12月4日之间的天数，有一切正常了！
心中万马奔腾啊！
经过一番探索，我又写了如下代码：
惊奇地发现：
进而又发现：

由此我灵机一动，又写了一段代码，找到从1900年至今所有当天长度非24小时的日期！

此中必有蹊跷！

豁然

然而这对于没文化的我来说，实在是一件不可理喻的事情。只能从源码入手了！

找源码的过程就不再赘述了，总之，时间的偏移来自于一个zoneOffsets的数组，而这个数组中除了因为时区而产生的偏移外，还有一个神秘的DST\_OFFSET！
找到这里，这个谜团即将揭晓了！
啥是DST\_OFFSET呢？
没错，daylight saving offset，也就是夏令时！
也就是说，中国的1990年4月15日这天里，人为地将时间拨快了一个小时，1990年9月16日这天再拨慢回来。进一步说，中国的1990年4月15日这天确实是23个小时，1990年9月16日这天也确实是25小时，Java没搞错！
也就是说之前找到的所有非24小时的日期，都是中国政府（或国民政府）施行夏令时调整的日期，这段历史断断续续地持续了半个多世纪！而Java的Calendar API将其忠实地记录了下来。
关于夏令时详情见百度百科。
哈哈哈，真相揭晓，好感慨好激动。所以说，这并不是Java的bug，而正是Java严谨的体现！Calendar API确实设计的很烂很不友好，但并不代表其中有bug，相反地，这也正体现了其中的工程师精神。

这就引出了一段已经被淡忘的历史，很多90年出生的朋友可以问问父母，90年和91年是我国至今为止实行夏令时的最后两年，我国曾经也想向美国等西欧国家学习，充分利用太阳下的时光！年轻的小朋友问问你们的父母，一定能勾起他们的一段回忆！
这就是隐藏在Java代码中的一段历史，一段已经被遗忘的人文故事！
想了解这段历史的同学可戳：
还记得大明湖畔的夏令时吗？
只要刨根问底，一定有意想不到的收获！感觉解决了个大谜团！