微信公眾號「後端進階」，專注後端技術分享：Java、Golang、WEB框架、分散式中介軟體、服務治理等等。
老司機傾囊相授，帶你一路進階，來不及解釋了快上車！
我發現資料庫有些日期居然用字串儲存？於是跟幾個小夥伴討論了關於資料庫的日期應該要怎麼儲存的問題，其實我一直都建議直接用數值儲存時間戳，為什麼我要這麼建議呢？
以下，我會從時區的概念來跟你們解釋一下，為什麼用數值儲存時間戳是最好的方案，同時也為了分享出來，讓更多開發小夥伴留意這些細節性的東西。
相信時區對於很多人來說的很熟悉，因為地球是圓的，在地球上不同角落看到的太陽上升的角度都是不同的，即每個人對於時間的顯示都是不一樣的，
舉個例子：
此時處於東 8 區的我們北京時間是 10 點，那麼處於東 1 區的時間就是 3 點，但是他們的時間是等價的：
"2019-06-20 10:00 +8:00" = "2019-06-20 3:00 +1:00"
複製程式碼所以說，對於不同時區的人來說，顯示的時間是不一樣的，那麼此時你是如何將將時間儲存到資料中的呢？
我姑且假設你用的是 new Date() 方法來儲存當時日期，但據我所知道的，資料庫的 DateTime 型別是沒有時區資訊的，如果你此時用 DateTime 格式儲存日期，就會丟失時區資訊，如果你的伺服器更該地址，從資料庫讀出來的日期資料就是錯誤的！
可能你會說，那我用 timeStamp 型別儲存總不會丟失時區資訊了吧？確實沒丟失，沒毛病。但是據我所知道的，timeStamp 儲存的時間最長不能超過 2037 年，而且你要考慮每個資料的 timeStamp 型別都有可能不一樣。
至於用字串來儲存時間，就更加不推薦了，姑且不從時區來說，你比較日期大小也是個問題，我舉個例子：
to_char(SYSDATE, 'yyyy-MM-dd') > START_TIME
複製程式碼要比較一個時間大小，我需要這麼做，還需要將系統時間轉成字串來給你對比，而且在轉換成字串比較時，資料庫內部也會將其轉換成時間來比較，你覺得這種查詢條件會好到哪裡去？
我們也知道在 JDK8 中新的時間 API LocalDateTime 中，有著豐富的時區轉換的方法可用，但即便你說你精通 LocalDateTime 的各種花式用法，你也不得不面對繁雜的轉換。
所以，我們需要一個擁有「絕對時間」，來幫助我們記錄日期，幫我們節省下轉換的時間，這個「絕對時間」就是時間戳，時間戳的定義是從一個基準時間開始算起，這個基準時間是「1970-1-1 00:00:00 +0:00」，從這個時間開始，用整數表示，以秒計時，隨著時間的流逝這個時間整數不斷增加。這樣一來，我只需要一個數值，就可以完美地表示時間了，而且這個數值是一個絕對數值，即無論的身處地球的任何角落，這個表示時間的時間戳，都是一樣的，生成的數值都是一樣的，並且沒有時區的概念，所以在系統的中時間的傳輸中，都不需要進行額外的轉換了，只有在顯示給使用者的時候，才轉換為字串格式的本地時間。
而且很重要的一點就是，在現有的程式語言中，都提供了方法來獲取時間戳，這對於我們不同語言的專案互動來說，不要太方便！所以在這裡我強烈建議前後端關於時間的互動，都用時間戳來互動。
這時，可能有同學又來槓一波，你用一個出數值來表示時間，我查資料庫時，以我的眼力和口算，根本不知道時間是多少，我覺得這個根本不需要擔心啊，你查資料庫無非是檢視需要的資料而已，你在 sql 裡面對時間戳個時間轉換函式就好了，比如：
from_unixtime(1561053690000)
複製程式碼如果你還要繼續槓，說我就是要在資料庫表中看到時間，我覺得如果你要這樣，為什麼還需要前端，直接拿資料庫當前端展示就好了。
我總結一下資料庫用數值儲存時間戳的諸多好處：
- 在資料庫中日期比較不要太方便，小學一年級就會的數學題，而且效能好；
- 數值對於任何系統互動來說都不存在障礙；
- 基於絕對時間的數值儲存，不存在時區問題；
- 在互動過程中，摒棄沒必要的重重轉換，一個數字走天下，使用者需要顯示，前端只需要拿到時間戳顯示正確的本地時間；
- 解決了由於各個資料庫對於時間實現的不一樣導致的問題，比如說 Mysql 的時間函式跟 Oracle 會有一些差別，假如你現在的 sql 有時間函式，換了資料庫很可能就會出錯。