作者：漫話程式設計 來自：漫話程式設計

問題復現

1970-01-01對於開發者來說都是不陌生的，有些系統對於時間的處理如果不夠好的話，就可能把時間顯示成1970-01-01，所以經常有使用者看到1970-01-01這個時間。

這種情況其實是很簡單就可以復現的，當我們嘗試使用以下Java程式碼定義時間：

Date date = new Date(0);System.out.println(date);打印出來的結果：

Thu Jan 01 08:00:00 CST 1970通過Date的建構函式的Java Doc說明我們也能得到一些蛛絲馬跡：

該建構函式接收使用者指定一個毫秒數，如new Date(1000)，表示獲得一個距離"epoch"有1000毫秒的時間。在Java中，這個時間是1970, 00:00:00 GMT。

時間戳

一切要從Unix作業系統誕生開始說起。

1969年8月，貝爾實驗室的程式設計師肯湯普遜利用妻兒離開一個月的機會，開始著手創造一個全新的革命性的作業系統，他使用B編譯語言在老舊的PDP-7機器上開發出了Unix的一個版本。

隨後，湯普遜和同事丹尼斯里奇改進了B語言，開發出了C語言，重寫了Unix，新版於1971年釋出。

在Unix被髮明出來之後，需要在Unix上表示時間，就需要想辦法定義一個能表示一份資料在某個特定時間之前已經存在的、完整的、可驗證的資料來表示時間。

於是，Unix時間戳被定義出來，即通過當前時間和一個"紀元時間"進行對比，其間相差的秒數作為時間戳。

為了讓Unix時間戳表示時間這種方式用的儘可能久，最初就把Unix誕生的時間1971-1-1定義成"紀元時間"。

時間戳修改

除了開始時間是1971-1-1而不是1970-1-1外，最初的時間戳也不是每增加1秒時間戳就變動一次，而是每1/60秒都會改變一次時間戳。

另外，Unix是在1971年發明出來的，當時的計算機系統是32位，如果用32表示有整數，那麼最大值是2147483647(2^31-1)。

那麼，簡單做一個數學計算，如果用當時的時間戳計算方式來表示時間的話，Unix時間戳最多可以使用4294967296/（60*60*24）/60 = 828.5天（一天有60*60*24秒，每1/60秒會佔用一個時間戳）。

想象一下，設計出一個計算機系統，他的時間只能表示 828.5天，是不是很難讓人接受，但是最初的Unix確實是這樣的。

後來，Unix的開發者們也漸漸意識到這樣不是長久之計，於是開始做出改變。

最開始，他們將每1/60秒改變一次時間戳修改成每1秒改變一次時間戳。這樣時間戳可以表示的時間就又放大了60倍。這時候有828.5*60/365 = 136年。

這時候，一方面136年已經足夠久了，紀元時間稍微向前調一下影響也不大。另外一方面為了方便記憶和使用。

於是就把紀元時間從1971-01-01調整到1970-01-01了。

於是，隨著後面各種開發語言的誕生，就都沿襲了1970-1-1這個設定。

所以，通常我們說的時間戳，就是指格林威治時間（GMT）1970年01月01日00時00分00秒起至現在的總秒數。

紀元時間與時區

我們前面所提到的紀元時間的設定，都是基於格林威治標準時間的，即GMT時間。

但是世界上各個地區有自己的時區，都需要基於GMT時間進行調整。

1970-01-01 08:00:00的顯示顯然是受到了時區《如何給女朋友解釋為什麼日本時間比中國快一個小時》的影響，因為中國處於東八區，所以時間會比標準時間早8小時，而標準時間應該是1970-01-01 00:00:00。

應該很多人都記得《蘋果"1970 事件"》，在幾年前，一個名為vista980622的網友在國外網站Reddit的論壇上發表了一篇“把iPhone時間改成1970年1月1日，手機即可永遠變磚”的帖子。

在該帖子釋出不久，很多人都不相信，抱著試試看的態度將手機的時間設定成1970年1月1日，結果手機關機後重新開機真的變磚了。

因為我們處於東八區，時間比標準時間要快8小時，如果我們把時間調整成1970-01-01 00:00:00，那麼標準時間就會是比這個時間少8小時，即1969年12月31日16時0分0秒。

但是，IOS裝置是以UTC時區(GMT時間)的1970年1月1日0點0時0秒為界限，數值為0，使用者把時間調整到1969年12月31日16時0分0秒，系統就要出現負值的時間。

系統版本為IOS 8.0至IOS 9.3 beta3，並且搭載64位處理器(即處理器為A7-A9X的裝置)的蘋果裝置都會觸發這個Bug，導致變磚！