I am currently writing a project interface. During the test, it was found that the normal functions were tested on the server, but there were always problems locally. After step-by-step investigation, the final locking problem was due to the function strtotime returning a false value, causing data insertion into the database to fail.
The same code has different running results. The reason is that the environment is inconsistent. Either the PHP version is different, or the number of bits is different.
This article mainly introduces to you the solution to the problem of PHP converting dates beyond 2038. The article provides detailed solutions and makes it easier for everyone to understand and learn through sample code. Friends who need it can follow Let's take a look, I hope it can help everyone.
My computer is 64-bit. There is an inconsistency in the number of bits in PHP. The server uses 64-bit, while my local one is 32-bit. And strtotime is passed in a string 2050-1-1 23:59:59. This parameter is greater than 2038-1-19 03:14:07, so it returns false directly under 32-bit PHP, while 64-bit PHP is not affected by Influence.
Y2K38 Vulnerability
The root cause of the above problems is the Y2K38 vulnerability, also known as the Unix Millennium Bug.
32-bit system or PHP
This vulnerability will affect all PHP and other programming languages that use UNIX timestamp integers to record time under 32-bit systems. The maximum time that an integer variable can be saved is January 19, 2038, 03:14:07. After this time is exceeded, the integer value will overflow.
64-bit system or PHP
The furthest date that can be saved under the 64-bit system is 21 times the current age of the universe - 29.2 billion years. So it will not be affected by this vulnerability.
How to detect
How to know whether your system is affected by this vulnerability. It's very simple, just use strtotime to convert a date greater than January 19, 2038 03:14:07. Or use the date function to convert a timestamp greater than 2147454847 to a date.
The following is a detailed demonstration
Method 1
echo date("Y-m-d H:i:s",2556115199);
If the above result returns 2050-12-31 23:59:59, then there is no problem. If it returns 1914-11-25 09:31:43, it will be affected.
Method 2
var_dump(strtotime("2050-12-31 23:59:59"));
If the above result returns 2556115199, then it is normal. If false is returned, it will also be affected.
Solution
Option 1
Change the system and PHP to 64-bit. This cost is relatively high, but it can permanently solve the problem.
Option 2
After version PHP5.2, a function DateTime is provided to temporarily solve the problem.
// 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
Manipulating dates through the DateTime class will not be affected by the Y2K38 vulnerability and can be supported as far as December 31, 9999
Related recommendations:
Example analysis of date and holiday conversion in php
About the usage summary of php date array
php date to timestamp, convert the specified date into a timestamp
The above is the detailed content of How to solve the error when converting dates beyond 2038 in PHP. For more information, please follow other related articles on the PHP Chinese website!