[程序员段子] 1927年12月31日午夜一秒谜案

虽说是程序员向，不过内容和编程本身其实并没什么太大关系，请各位听我细细道来。

StackOverflow是一个程序员向的问答网站，广大程序员们在上面交流经验、提问答疑，三天前，一位名叫Freewind的用户发布了下面这个问题：

我在用Java编写一段比较两个字符串时间间隔的程序，然而当我比较“1927-12-31 23:54:07”和“1927-12-31 23:54:08”这两个时间时，输出结果却不是1……而是353。

当我把两个时间分别往后调整1秒，变成“1927-12-31 23:54:08”和“1927-12-31 23:54:09”，结果就又是1了！——可为什么那两个时间的结果，却是353呢？

面对这一诡异的问题，网友们很快追问，“你的区域（Locale）设置是什么？这可能是个区域问题/和当地夏令时之类的东西有关。”

楼主很快附上了Java版本号和区域设置：

sun.util.calendar.ZoneInfo[id=”Asia/Shanghai”,
offset=28800000,dstSavings=0,
useDaylight=false,
transitions=19,
lastRule=null]

（……没错，Freewind君，似乎是一位魔都死程。不知道这里有没有人认识这位老兄？）

在这份追加信息出现仅仅两分钟之后，StackOverflow站上的问答狂人Jon Skeet给出了如下答复——

这是因为上海的时区在12月31日发生了变化。

请看这里。（网页截图如下）

（1928年1月1日0点0分，当地时间由地方平时（Local Mean Time）改为北京时间/中国标准时间）

简单地说，在1927年末的最后那一个午夜，时钟被往回拨了5分52秒。所以“1927-12-31 23:54:08”这一秒，事实上，发生了两次，而看起来在计算当地时间时，Java将其视为了后面那一个时间点，于是就产生了这一差别。

这正是时区世界的奇妙与不可思议啊。

在StackFlow网民们纷纷膜拜Jon Skeet的神速之时，其他程序员也以测试的方式验证了这一结果的正确——美国时间木有这个问题。看来，当一枚程序员，有时真的需要上通天文、下知地理啊……