為什么計算機起始時間是1970年1月1日

傅一平

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

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

1.Date date = new Date（0）；

2.System.out.println（date）。

打印出來的結果：

Thu Jan 01 08：00：00 CST 1970

通過Date的構造函數的Java Doc說明我們也能得到一些蛛絲馬跡：

該構造函數接收用戶指定一個毫秒數，如new Date（1000），表示獲得一個距離"epoch"有1000 ms的時間。在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 s改變一次時間戳修改成每1 s改變一次時間戳。這樣時間戳可以表示的時間就又放大了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 h，而標準時間應該是1970-01-01 00：00：00。

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

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

因為我們處于東八區，時間比標準時間要快8 h，如果我們把時間調整成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，導致變磚。