我發現資料庫有些日期居然用字串儲存？於是跟幾個小夥伴討論了關於資料庫的日期應該要怎麼儲存的問題，其實我一直都建議直接用數值儲存時間戳，為什麼我要這麼建議呢？
以下，我會從時區的概念來跟你們解釋一下，為什麼用數值儲存時間戳是最好的方案，同時也為了分享出來，讓更多開發小夥伴留意這些細節性的東西。
相信時區對於很多人來說的很熟悉，因為地球是圓的，在地球上不同角落看到的太陽上公升的角度都是不同的，即每個人對於時間的顯示都是不一樣的
舉個例子：
此時處於東 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 有時間函式，換了資料庫很可能就會出錯。
執行緒的正確結束方式
在使用c語言進行多執行緒程式設計時，最重要的是執行緒怎麼結束，而不是它怎麼開始。多執行緒程式設計的主要問題，是需要執行緒 正確 結束，我們在程式設計中應該盡量避免使用系統提供的使執行緒強制結束的函式，而應該使用一定的同步方式，保證執行緒分配的資源得到正確地處理，避免記憶體洩漏。很多人在進行多執行緒程...
論啃書的正確方式
一下午的時光總是過得很快，有時候 一不小心 就浪費很多時間。不管你有沒有過這樣的情況，反正我是有。以下是我列出來的放縱的三個過程 1 感到有點枯燥，來點東西爽爽 2 就一點點，沒有關係的 3 啊 做這個果然是比啃書順暢多了，我剛才計畫是什麼？管它呢！就是1 2 3這樣走著，當你覺得太過分的時候就會從...
Redis的正確安裝方式
一 軟體準備 vmware 11.0 centos 6.4 redis 2.8.19 securecrt 7.2.2 redisclient 2.0.0 二 正式安裝 第0步 讓普通使用者具備sodu執行許可權 下面內容必須在linux中嚴格執行 su password hadoop vi etc ...