本文經授權轉載自微信公眾號：后端進階

我發現數據庫有些日期居然用字符串保存？于是跟幾個小伙伴討論了關于數據庫的日期應該要怎么保存的問題，其實我一直都建議直接用數值保存時間戳，為什么我要這么建議呢？

以下，我會從時區的概念來跟你們解釋一下，為什么用數值保存時間戳是最好的方案，同時也為了分享出來，讓更多開發小伙伴留意這些細節性的東西。

相信時區對于很多人來說的很熟悉，因為地球是圓的，在地球上不同角落看到的太陽上升的角度都是不同的，即每個人對于時間的顯示都是不一樣的，

舉個例子：

此時處于東 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, '2019-06-01 00:00:00') > START_TIME

要比較一個時間大小，我需要這么做，還需要將系統時間轉成字符串來給你對比，而且在轉換成字符串比較時，數據庫內部也會將其轉換成時間來比較，你覺得這種查詢條件會好到哪里去？

我們也知道在 JDK8 中新的時間 API LocalDateTime 中，有著豐富的時區轉換的方法可用，但即便你說你精通 LocalDateTime 的各種花式用法，你也不得不面對繁雜的轉換。

所以，我們需要一個擁有「絕對是時間」，來幫助我們記錄日期，幫我們節省下轉換的時間，這個「絕對時間」就是時間戳，時間戳的定義是從一個基準時間開始算起，這個基準時間是「1970-1-1 00:00:00 +0:00」，從這個時間開始，用整數表示，以秒計時，隨著時間的流逝這個時間整數不斷增加。這樣一來，我只需要一個數值，就可以完美地表示時間了，而且這個數值是一個絕對數值，即無論的身處地球的任何角落，這個表示時間的時間戳，都是一樣的，生成的數值都是一樣的，并且沒有時區的概念，所以在系統的中時間的傳輸中，都不需要進行額外的轉換了，只有在顯示給用戶的時候，才轉換為字符串格式的本地時間。

而且很重要的一點就是，在現有的編程語言中，都提供了方法來獲取時間戳，這對于我們不同語言的項目交互來說，不要太方便！所以在這里我強烈建議前后端關于時間的交互，都用時間戳來交互。

這時，可能有同學又來杠一波，你用一個出數值來表示時間，我查數據庫時，以我的眼力和口算，根本不知道時間是多少，我覺得這個根本不需要擔心啊，你查數據庫無非是查看需要的數據而已，你在 sql 里面對時間戳字段加個轉換函數就好了，比如：

from_unixtime(1561053690000)

以上時間戳是我寫這篇文章的時間。

如果你還要繼續杠，說我就是要在數據庫表中看到時間，我覺得如果你要這樣，為什么還需要前端，直接拿數據庫當前端展示就好了。

我總結一下數據庫用數值保存時間戳的諸多好處：

1.在數據庫中日期比較不要太方便，小學一年級就會的數學題，而且性能好；2.數值對于任何系統交互來說都不存在障礙；3.基于絕對時間的數值存儲，不存在時區問題；4.在交互過程中，摒棄沒必要的重重轉換，一個數字走天下，用戶需要顯示，前端只需要拿到時間戳顯示正確的本地時間；5.解決了由于各個數據庫對于時間實現的不一樣導致的問題，比如說 Mysql 的時間函數跟 Oracle 會有一些差別，假如你現在的 sql 有某些時間函數，換了數據庫很可能就會出錯。

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的日期居然用字符串保存？我笑了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。