到底是怎么回事呢？
我们回到 stackoverflow 接着往下看：
这是他第一次修改回答，因为 History changes...
历史发了变化了...
他这里说，如果用 TZDB 的 2013a 版本的数据，原来的问题将不再表现出完全相同的行为。
在 2013a 中，结果将是 358 秒，过渡时间为 23:54:03，而不是 23:54:08。
他提到了一个 TZDB，这是个啥东西呢？
我也不知道，但是我搜索了一下。
他应该说的是这个的东西。
看名字你也知道了，它是一个时区数据库，里面应该是维护的时区相关的数据。
也就是说，在这个时区数据库里面，用 2013a 版本的数据，前面的代码就是另外一种输出了。
也就是说数据确实发生了变化。
而关键的回答在于下一次编辑：
History has changed again...
历史再次发生了变化。
在个时区数据库里面，2014f 版本中，变化的时间已经移到了1900-12-31，现在只是一个 343 秒的变化。
343 秒？
不就是我们前面的 5 分 43 秒吗？
好了，现在时差能对上了，343 秒，但是时间还是没对上啊。
我们的测试时间 1900-01-01 08:00:00，他这里写的时间是 1900-12-31。
差了整整一年呢？
好，我们看他最后一次编辑的内容：
我个人理解他要表达的意思是这样的。
Java 为了在时区上统一标准，所以来了个一刀切的政策。
统一的标准就是让 UTC 时区下 1900 年之前的任何瞬间都是标准时间。
至于产生的时差嘛...
就在最开始的时候补上去吧。
所以，1900-01-01 00:00:00 加上 8 小时时差，是 1900-01-01 08:00:00，在这个基础上预先加上 27 年后来自 1927-12-31 那个午夜由于时间回拨带来的 343 秒。
1900-01-01 08:05:43，我个人认为就是这样来的。
而前面 stackoverflow 里面对应的那个程序，我们现在执行是输出 1，但是在 10 年前，输出结果确实是 353 。
就像我把程序改成这样：
最终的输出结果不是 1，而是 -342。
时间，发生了“倒流”。
好了，又是一个没啥卵用的知识点。
最后，再补充一个冷知识。
第一个是我在 jdk bug 列表里面追溯了一下，能找到最早提出相关问题的时间是 2005 年：
在这个里面，官方是这样回复的：
这个问题不会被修复，以避免任何兼容性问题。
意思就是：问题我知道了，但是这玩意不太好弄，bug 先变成 feature 吧，就先这样吧。
别问，问就是有历史原因在里面。
最后说一句
好了，看到了这里了，转发、在看、点赞随便安排一个吧，要是你都安排上我也不介意。写文章很累的，需要一点正反馈。
给各位读者朋友们磕一个了：
