大寶庫

來源:http://news.cnd8.com/news/48702.htm

雖說是程序員問的，不過內容和編程本身其實并沒什么太大關系，請各位聽我細細道來。StackOverflow是一個程序員向的問答網站，廣大程序員們在上面交流經驗、提問答疑，三天前，一位名叫Freewind的用戶發布了下面這個問題：
　　

我在用Java編寫一段比較兩個字符串時間間隔的程序，然而當我比較“1927-12-3123:54:07”和“1927-12-3123:54:08”這兩個時間時，輸出結果卻不是1……而是353。
　　
當我把兩個時間分別往后調整1秒，變成“1927-12-3123:54:08”和“1927-12-3123: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站上的問答狂人JonSkeet給出了如下答復——
　　
　　這是因為上海的時區在12月31日發生了變化。
　　
　　請看這里。（網頁截圖如下）
　　

　　（1928年1月1日0點0分，當地時間由地方平時（LocalMeanTime）改為北京時間/中國標準時間）
　　
　　簡單地說，在1927年末的最后那一個午夜，時鐘被往回撥了5分52秒。所以“1927-12-3123:54:08”這一秒，事實上，發生了兩次，而看起來在計算當地時間時，Java將其視為了后面那一個時間點，于是就產生了這一差別。
　　
　　這正是時區世界的奇妙與不可思議啊。
　　
　　在StackFlow網民們紛紛膜拜JonSkeet的神速之時，其他程序員也以測試的方式驗證了這一結果的正確——美國時間木有這個問題。看來，當一枚程序員，有時真的需要上通天文、下知地理啊……