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


轉載

   https://juejin.im/post/5ee6eb8751882542f448aa43

問題復現

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

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

  

@Test
public void date0Test() {
     //
     Date date = new Date(0);
     System.out.println(date);
 }

  打印出來的結果:

Thu Jan 01 08:00:00 CST 1970 

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

 1 /**
 2      * Allocates a <code>Date</code> object and initializes it to
 3      * represent the specified number of milliseconds since the
 4      * standard base time known as "the epoch", namely January 1,
 5      * 1970, 00:00:00 GMT.
 6      *
 7      * @param   date   the milliseconds since January 1, 1970, 00:00:00 GMT.
 8      * @see     java.lang.System#currentTimeMillis()
 9      */
10 public Date(long date) {
11     fastTime = date;
12 }

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

  至於"epoch"是個啥呢? 這個一般認為是"紀元時間", 直接認為是1970-01-01就行了!

  那為啥"紀元時間"就是1970-01-01呢? 這就要從Unix操作系統誕生開始說起

時間戳

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

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

  在Unix被發明出來之后,需要在Unix上表示時間,就需要想辦法定義一個能表示一份數據在某個特定時間之前已經存在的、完整的、可驗證的數據來表示時間。

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

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

  其實最開始確實"紀元時間"用的是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秒起至現在的總秒數。  

  那問題來了, 如果只能用136年, 那豈不是2106年之后的計算機時間就不能用了? 其實不是的, 因為現在計算機已經不是當時的32位系統了, 目前64位已經很普遍了, 64位系統可以表示292,277,026,596年(2000多億), 這樣就不怕了

紀元時間與時區

  我們前面所提到的紀元時間的設置,都是基於格林威治標准時間的,即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,導致變磚!

  

  

  


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM