問題複現
1970-01-01對于開發者來說都是不陌生的，有些系統對于時間的處理如果不夠好的話，就可能把時間顯示成1970-01-01，是以經常有使用者看到1970-01-01這個時間。
這種情況其實是很簡單就可以複現的，當我們嘗試使用以下java代碼定義時間：
列印出來的結果：
通過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時間戳最多可以使用<code>4294967296/（60*60*24）/60 = 828.5</code>天（一天有<code>60*60*24</code>秒，每1/60秒會占用一個時間戳）。
想象一下，設計出一個計算機系統，他的時間隻能表示 828.5天，是不是很難讓人接受，但是最初的unix确實是這樣的。
後來，unix的開發者們也漸漸意識到這樣不是長久之計，于是開始做出改變。
最開始，他們将每1/60秒改變一次時間戳修改成每1秒改變一次時間戳。這樣時間戳可以表示的時間就又放大了60倍。這時候有<code>828.5*60/365 = 136</code>年。
這時候，一方面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，導緻變磚！