先說一下mysql中DATETIME和TIMESTAMP的區別
TIMESTAMP是標准的unix timestamp，它存儲的是1970-1-1到現在經過的秒數，4字節存儲。mysql用這個類型還蠻方便的，一個是有很多內置的函數和trigger來處理它，比如CURRENT_TIMESTAMP宏，最關鍵的是在取數據的時候mysql會自動幫你處理DST和時區的問題。
DATETIME的范圍更大，好像可以從0000-00-00 00:00:00到9999-12-31 23:59:59，8字節存儲，當然mysql內部肯定也是用整數而不是字符串的（說了是8字節了），所以效率不是大問題。但DATETIME不帶時區，比如我在程序里生成了一個2015-05-07 15:26:00的時間（實際上是+8時區的，但這個對象可能是timezone naive）的，存到mysql里，再從不同時區的地方拿出來，這個時間可能就混了。
但TIMESTAMP也有兩個很大的問題：
- 4字節長度限制，它只能到2038年
- 很多時候我們希望根據用戶所在地的時區顯示時間而不是光顯示一個服務器時間
所以比較好的做法是，數據庫中使用DATETIME，然后存時間的時候一律用程序生成UTC時間（而不是local時區的時間）存進去，取出來的時候不管想顯示服務器時間還是顯示用戶的時間都可以處理。
順便提一句，根據用戶所在地時區顯示時間有兩種做法：
- 當用戶第一次訪問網站的時候，用js獲取時區發送到服務器上存到session里
- 用js處理時間的顯示（我覺得這種比較方便一點，畢竟不用改服務端代碼）
Java獲取當前UTC時間戳（毫秒）
public static String getUTCTimeStr() throws Exception {
Calendar cal = Calendar.getInstance();
return String.valueOf(cal.getTimeInMillis() / 1000);// 返回的就是UTC時間
}
使用這種做法的唯一缺點是sqlite3沒有internal的DATETIME類型，所以在ORM框架如sqlalchemy中，它會直接存字符串進去。（sqlite3的文檔也說，你要么存成int要么real要么字符串）。盡管這可能帶來一些不方便和性能的下降，但我認為還是符合“keep it simple and stupid”的原則。
至於用INT存時間，是另一種可行的方法，參見http://www.liaoxuefeng.com/article/0014132675721847f569c3514034f099477...
我個人不是很喜歡這么做，因為這樣你必須把模型中表示時間的成員聲明為int類型。這樣是比較不符合邏輯的（那些Date呀Datetime之類的類就沒有用了呀，最多就有個Dateutil就好了），而且會使得程序不易讀（卧槽這個publishedDate為什么是int，它到底表示的是時間嗎？）。總之見仁見智。