代码中的人文故事：从一个Java的“Bug”说起
缘起
这几日闲来无事撸代码，无意中发现一桩趣事。原以为是一个Java的bug，没想到经过一系列死磕，挖掘出了一段和中国历史乃至人类文明相关联的人文故事，不禁唏嘘感叹一番。
这件事的缘起很简单，我在实现计算两个日期天数距离逻辑的过程中，发现了一个很诡异的事情，同样的起始日期，用python和Java计算出的结果居然不一样！
例如，计算一个1990年1月1日到1990年9月4日之间的天数，用python计算如图：
得出天数为246。可以看到，python的API设计简单。
用Java计算则不同了，众所周知Java推荐的Calendar API不是一般的麻烦，实现函数如下：
按照这个逻辑测试如下：
WTF!?得出的天数居然是245天？为什么和Python算出来的不一样？我马上实际数了一下，应该是246天，Python算的结果是对的！
仔细核对了程序实现，没毛病啊？难道有精读损失？
狐疑（懵逼）
进而加入如下输出：
什么鬼？这0.0416666667天跑哪里去了？需知：
也就是说，Java计算的时间和实际正好差了一个小时！
无独有偶，各种百度后，居然发现了和我有类似疑问的兄弟：
https://ask.csdn.net/question...
然而这个提问下并没有靠谱的答案！
这样看，似乎很像时区上出了问题，然而并不是，前后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代码中的一段历史，一段已经被遗忘的人文故事！
想了解这段历史的同学可戳：
还记得大明湖畔的夏令时吗？
只要刨根问底，一定有意想不到的收获！感觉解决了个大谜团！
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
