PHP用int來儲存時間，可最大限制2038年吧，等到2038年以後可怎麼辦啊？

那2038年之後可怎麼辦啊？

回複內容：

那2038年之後可怎麼辦啊？

那是32位系統才是，目前64位並不存在這個問題。

維基百科對於2038問題的解釋

在電腦應用上，2038年問題可能會導致某些軟體在2038年1月19日3時14分07秒之後無法正常工作。所有使用POSIX時間表示時間的程式都將受其影響，因為它們以自1970年1月1日經過的秒數（忽略閏秒）來表示時間。這種時間標記法在類Unix（Unix-like）作業系統上是一個標準，並會影響以其C程式設計語言開發給其他大部分作業系統使用的軟體。在大部分的32位作業系統上，此“time_t”資料模式使用一個有加號或減號的32位整數（signed int32）儲存計算的秒數。依照此“time_t”標準，在此格式能被表示的最後時間是2038年1月19日03:14:07，星期二（UTC）。超過此一瞬間，時間將會“繞回”（wrap around）且在內部被表示為一個負數，並造成程式無法工作，因為它們無法將此時間識別為2038年，而可能會依個別實現而跳回1970年或1901年。錯誤的計算及動作可能因此產生。

目前並沒有針對現有的CPU／作業系統搭配的簡單解決方案。直接將POSIX時間更改為64位元模式將會破壞對於軟體、資料存放區以及所有與二進位表示時間相關的部分的二進位相容性。更改成無符號的32位整數則會影響許多與兩時間之差相關的程式。不過，那時使用32位系統的電腦可能會很少。

大部分64位作業系統已經把time_t這個系統變數改為64位寬。不過，其他現有架構的改動仍在進行中，不過預期“應該可以在2038年前完成”。然而，直到2006年，仍然有數以億計的32位系統在運行中，特別是許多嵌入式系統。相對於一般電腦科技18至24個月的革命性更新，嵌入式系統可能直至使用壽命終結都不會改變。32位time_t的使用亦被編碼於檔案格式，例如眾所周知的ZIP壓縮格式。其能存在的時間遠比受影響的機器長。

新的64位元運算器可以記錄至約2900億年後的292,277,026,596年12月4日15:30:08，星期日（UTC）。

想想2000年的時候的千年蟲事件吧，當時不是嘛事沒有嘛

表示少年你多慮了，第一個你的程式肯定達不到22年的生命週期。
第二個你非要用int儲存時間，就像有飛機坐，你非要遊泳去美國，還問到時候遊不到怎麼辦。

儲存時間的的是MySQL資料庫。而PHP只是取出欄位用字串操作。
MySQl中有多種表示日期和時間的資料類型。其中YEAR表示年份，DATE表示日期，TIME表示時間，DATETIME和TIMESTAMP表示日期和實踐。它們的對比如下：

TEAR ，位元組數為1，取值範圍為“1901——2155”

DATE，位元組數為4，取值範圍為“1000-01-01——9999-12-31”

TIME，位元組數為3，取值範圍為“-838:59:59——838:59:59”

DATETIME，位元組數為8，取值範圍為“1000-01-01 00:00:00——9999-12-31 23:59:59”

TIMESTAMP，位元組數為4，取值範圍為“19700101080001——20380119111407”

當插入值超出有效取值範圍時，系統會報錯，並將零值插入到資料庫中。

