在 MySQL at Facebook 的這邊說明提到了,Facebook 內部是使用 INT UNSIGNED
儲存時間:
Which gets us to the point that it is no different than storing INT (hello 2038?) or UNSIGNED INT (a bit later) or BIGINT (till the end of time) and possibly passing binary values in efficient protocols eventually.
If you got that far of this post, your likes in Facebook graph are stored with 'INT UNSIGNED' time field.
順道一提,INT
是 2038 年問題,INT UNSIGNED
是 2106 年問題。
而 Facebook 在 MySQL 上會選擇不使用 DATETIME
與 TIMESTAMP
的原因其實跟技術搭不上太多關係,主因是因為 MySQL 根本沒打算修 XDDD
It is my favorite MySQL bug, simply because it forces any reasonable mind not to use TIMESTAMP, and MySQL is never going to fix it (nor will ever understand time). I lost my temper a bit on that bug: https://bugs.mysql.com/bug.php?id=38455
我的猜測是已經爛成一團了,而且大家都有 workaround (呃,其實就是 Facebook 推薦用 INT UNSIGNED 的方法),再考慮到有一票現有程式,在上面狂用 side effect 讓執行結果正確,不如就不要修這種吃力不討好的東西了 XDDD
另外一方面 timezone 資訊其實常常變化,常常需要更新 MySQL 的 timezone database (而這對於維運來說不是什麼開心的事情):
There're few ways around that. One of them is side-load and maintain timezone data inside MySQL itself - it has support for internal timezone database and tracks obscure time shifts like ones for "Pacific War Time" and "Pacific Peace Time". That is operationally feasible (you have to remind yourself to update the database whenever time rules change, and they do change a lot, if you consider every timezone in the world), but has limited value.
這就是為什麼大家遇到 MySQL 時都會推薦用 INT UNSIGNED
了...
另外可以參考三年前的文章「MySQL 裡儲存時間的方式...」,裡面引用了 Baron Schwartz 的說明:
All date and time columns shall be
INT UNSIGNED NOT NULL
, and shall store a Unix timestamp in UTC.
其實這已經是個 best practice 了...