最近在寫一個項目接口。測試中發現服務器上測試正常的功能,在本地一直有問題。一步步的排查,最終鎖定問題是因爲函數strtotime
返回了一個false
值,致使數據插入數據庫失敗。php
我的博客文章地址:http://www.weiya.me/item/61.htmlhtml
相同代碼運行結果不同,緣由那就是環境不一致致使。要麼是PHP
版本不一樣,要麼是位數不一樣。數據庫
我電腦是64位的。這裏是PHP位數不一致,服務器使用64位,而我本地是32位。而strtotime
被傳入了一個字符串2050-1-1 23:59:59
,該參數大於了2038-1-19 03:14:07
因此在32位PHP下直接返回false
,而64位PHP不受影響。編程
致使上述問題的根本緣由就是Y2K38
漏洞,也被稱爲Unix Millennium Bug
。服務器
此漏洞將會影響到全部 32 位系統下用UNIX
時間戳整數來記錄時間的 PHP
,及其它編程語言。一個整型的變量所能保存的最大時間爲 2038 年01月19 日 03:14:07
。超過這個時間後,整型數值將會溢出。編程語言
64位系統下能夠保存的日期最遠日期是如今宇宙年齡的21倍——292億年。因此不會受到該漏洞影響。函數
如何知道你的系統是否收到該漏洞的影響。很簡單,直接使用strtotime
去轉換一個大於2038年1月19日03:14:07日期。或者使用date
函數將一個大於2147454847
時間戳轉換爲日期。測試
下面具體演示一下code
echo date("Y-m-d H:i:s",2556115199);
上面結果若是返回2050-12-31 23:59:59
那麼就沒有問題。若是返回1914-11-25 09:31:43
那麼就受收到影響。orm
var_dump(strtotime("2050-12-31 23:59:59"));
上面結果若是返回2556115199
那麼就正常。若是返回false
那麼也會受到影響。
更換系統和PHP
均爲64位。這個代價比較大,可是能夠永久解決問題。
PHP5.2
版本以後提供了一個函數DateTime
能夠臨時解決一下問題。
// 一、日期字符串轉換爲時間戳 $obj = new DateTime("2050-12-31 23:59:59"); echo $obj->format("U"); // 2556115199 // 二、時間戳轉換爲日期字符串 $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日