最近在寫一個專案介面。測試中發現伺服器上測試正常的功能，在本地一直有問題。一步步的排查，最終鎖定問題是由於函數strtotime返回了一個false值，導致資料插入資料庫失敗。
相同程式碼運行結果不一樣，原因就是環境不一致導致。要嘛是PHP版本不同，要嘛是位數不同。
本文主要和大家介紹了關於PHP轉換超過2038年日期出錯問題的解決方法，文中給出了詳細的解決方法，透過範例程式碼讓大家更容易理解和學習，需要的朋友們下面來一起看看吧，希望能幫助大家。
我電腦是64位元的。這裡是PHP位數不一致，伺服器使用64位，而我本地是32位。而strtotime被傳入了一個字串2050-1-1 23:59:59，這個參數大於了2038-1-19 03:14:07所以在32位PHP下直接回傳false，而64位PHP不受影響。
Y2K38漏洞
導致上述問題的根本原因是Y2K38漏洞，也稱為Unix Millennium Bug。
32位元系統或PHP
此漏洞將會影響到所有 32 位元系統下以UNIX 時間戳整數來記錄時間的 PHP，及其它程式語言。一個整型的變數所能保存的最大時間為 2038 年01月19 日 03:14:07。超過這個時間後，整數數值將會溢位。
64位元系統或PHP
64位元系統下可以保存的日期最遠日期是現在宇宙年齡的21倍——292億年。所以不會受到該漏洞影響。
如何偵測
如何知道你的系統是否會收到該漏洞的影響。很簡單，直接使用strtotime去轉換一個大於2038年1月19日03:14:07日期。或使用date函數將一個大於2147454847時間戳轉換為日期。
下面具體示範一下
方法一
echo date("Y-m-d H:i:s",2556115199);上面結果如果回傳2050-12-31 23:59:59那麼就沒有問題。如果返回1914-11-25 09:31:43那麼就受收到影響。
方法二
var_dump(strtotime("2050-12-31 23:59:59"));上面結果如果回傳2556115199那麼就正常。如果回傳false那麼也會受到影響。
解
方案一
更換系統和PHP均為64位元。這個代價比較大，但是可以永久解決問題。
方案二
PHP5.2版本之後提供了一個函數DateTime可以暫時解決問題。
// 1、日期字符串转换为时间戳
$obj = new DateTime("2050-12-31 23:59:59");
echo $obj->format("U"); // 2556115199
// 2、时间戳转换为日期字符串
$obj = new DateTime("@2556115199"); // 这里时间戳前要写一个@符号
$timezone = timezone_open('Asia/HONG_KONG'); // 设置时区
$obj->setTimezone($timezone);
echo $obj->format("Y-m-d H:i:s"); // 2050-12-31 23:59:59
// 而且DateTime还可以有其他玩法
$obj = new DateTime("2050-12-31 23:59:59");
echo $obj->format("Y/m/d H:i:s"); // 换种方式输入时间字符串2050/12/31 23:59:59透過DateTime類別來操作日期不會受到Y2K38漏洞的影響，可以最遠支持到9999年12月31日
#相關推薦：
以上是PHP轉換超過2038年日期出錯如何解決的詳細內容。更多資訊請關注PHP中文網其他相關文章！
