@ 2011.07.30 , 19:49

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

via StackOverflow

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

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的神速之时,其他程序员也以测试的方式验证了这一结果的正确——美国时间木有这个问题。看来,当一枚程序员,有时真的需要上通天文、下知地理啊……


给这篇稿打赏,让译者更有动力 !
支付宝打赏 [x]
您的大名: 打赏金额:

4.7
赞一个 (5)

24H最赞