上週有同事問到幾個和時間相關的問題，非常有意思，之前也沒怎麼想過，不知道大家是否想過這幾個問題

• 在mac下發現System.nanoTime()在JDK7和JDK8下輸出的值怎麼完全不一樣
• System.nanoTime()的值很奇怪，究竟是怎麼算出來的
• System.currentTimeMillis()為何不是System.nanoTime()的1000倍

這幾個問題歡迎大家在這篇文章之後發表下自己的看法，如果大家都知道我就不準備寫System.currentTimeMillis()和System.nanoTime()的具體實現的文章啦

不過今天要簡單聊下另外一個有意思的問題，也是剛剛突然想到的問題，為何我們執行System.out.println(new Date(0));

的時候，輸出的是Thu Jan 01 08:00:00 CST 1970，為何是1970年1月1日，也許大家對1970年1月1日並不陌生，但是從來沒有想過這個問題吧，我也其實也沒詳細想過，於是也查資料，看程式碼，看到分析結果還挺有意思的，於是打算簡單寫出來給沒了解過的朋友漲漲姿勢，網上這方便的資料還是不少的，需要詳細解釋的，自己查查，哈哈

最初作業系統是32位的，當然現在有不少已經轉到64位上了，那個時候的時間也是用32位來表示的，那麼能表示的最大值是2^32-1=2147483647，而這個值算下來2147483647/(365 * 24 * 60 * 60)=68.1年，而當時unix作業系統最早由KenThompson

、Dennis Ritchie和Douglas McIlroy於1969年在AT&T的貝爾實驗室開發，為了讓這個32位能全部利用起來，就用來存個相對1970年1月1日的時間了(那個時候unix的計算機估計才慢慢生產)，這樣一來，當時間達到68.1年的時候，對應的時間是2038年1月19日3時14分7秒，到這天的凌晨3時14分8秒就會出現溢位情況了，時間會變成1901年12月13日20時45分52秒，或許大家聽過以前的千年蟲問題吧，如果2038年大家還在32位上玩，那估計會很糟糕了，所以大家儘快到64位上來玩吧

Java因為也遵循了unix的這套時間標準，所以我們能看到上面的現象。