你的PHP項目中還在用時間戳記嗎？

time()的最大範圍是 1901 年 12 月 13 日 20:45:54 到 2038 年 1 月 19 日 03:14:07。

還有20年時間，這時候寫項目還要用時間戳記嗎？

如果一直用時間戳記形式，到了2038年，有什麼替代方案？

回複內容：

time()的最大範圍是 1901 年 12 月 13 日 20:45:54 到 2038 年 1 月 19 日 03:14:07。

還有20年時間，這時候寫項目還要用時間戳記嗎？

如果一直用時間戳記形式，到了2038年，有什麼替代方案？

不需要擔心，到時候官方會升級PHP版本解決

這個是系統的事 ，是當時設計的32位達到了上限。
可以用64位。
也可以不用管，反正到時候你肯定不再寫代碼了，而且，20年的時間，你確定你的項目可以活那麼久？

參考資料：
http://stackoverflow.com/questions/5826219/time-after-2038
http://stackoverflow.com/questions/2012589/php-mysql-year-2038-bug-what-is-it-how-to-solve-it
https://en.wikipedia.org/wiki/Year_2038_problem

你們提問和回答之前有做過驗證嗎？僅僅只憑腦中一想就決定了php有2038bug？

～# date -s 2040/12/20
Thu Dec 20 00:00:00 CST 2040

～# php -r "echo time();"
2239545608

～# php -r "echo date('Ymd His;" time());
20401220 000015

當然，你們在32位的Windows xp上開發，你們活該low

必須嚴肅的指明一個問題：由於可能處理未來的日期，所以2038問題在少部分應用中“到時解決”也已經晚了，必須提前應對。例如：萬年曆、時間戳記計算、貸款計算等程式。

但是與C/C++/C#/Rust這樣的靜態類型語言不同，PHP對整形的類型限定是極弱的——PHP的整形僅僅等同於平台上的signed int，不支援unsigned，也不支援縮短取值範圍（官方文檔）。

因此對PHP程式本身而言，時間戳記數字和相關的DateTime對象，能夠無修改的遷移到64位從而解決2038年問題。

比較麻煩的是資料庫部分。目前大致的狀況是：

• MySQL的TIMESTAMP使用int32，所以只支援到2038

• MySQL的各種相容實現，基本上有同樣的問題

• PgSQL的timestamp底層儲存使用int64，上層卡一個公元1465001年的上限值

• SQLite根本不提供日期類型，自己用bigint存就好了

簡而言之：如果你確有立刻儲存2038年以後時間戳記的需求，請在MySQL中直接使用BIGINT。

long夠用嗎？php的時間戳記我記得是沒毫秒部分的

還在使用時間戳 別的我不知道眼前的需求當然是眼前的方法來滿足和實現

ISO 8601

20年你的項目已經老掉牙了 所以不用擔心 PHP版本更新下這問題就解決了

讓人想起了當年的千年蟲問題

請使用DateTime類來處理

想想有次做個項目，我判斷如果超過了2025年，後面的邏輯就失效了，反正到時候這個項目肯定活不了那麼久，就好笑。

32位MySQL也是可以使用bigint類型儲存64位整數的,再不放心,你可以用varchar嘛.時間戳記欄位類型用bigint,64位整型最大值(2^64)/2-1=9223372036854775807足夠了.伺服器用64位Linux,這時PHP_INT_MAX的最大值也為(2^64)/2-1=9223372036854775807.

那個時候代碼肯定不時我維護，啊哈哈哈

那個時候 = = 我不知道還寫不寫代碼。。。。

