Recently in writing a project interface. The tests found a normal function on the server and there has been a problem locally. Step by step troubleshooting, the final locking problem is that the function Strtotime returns a false value, which causes the data to be inserted into the database failure.
The same code runs differently, because the environment is inconsistent. Either the PHP version is different or the number of digits is different.
This article mainly and you introduced the PHP conversion more than 2038 date error problem resolution method, the article gives a detailed solution, through the sample code to make it easier to understand and learn, the need for friends below to see together, hope to help everyone.
My computer is 64-bit. Here is the number of PHP bits inconsistent, the server uses 64 bits, and my local is 32 bit. While Strtotime was passed a string of 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.
y2k38 Vulnerability
The root cause of the above problem is the y2k38 vulnerability, also known as the Unix Millennium Bug.
32-bit system or PHP
This vulnerability would affect PHP, and other programming languages, that use a Unix timestamp integer to record time in all 32-bit systems. The maximum time a variable of an integral type can be saved is January 19, 2038 03:14:07. After this time, the integer value will overflow.
64-bit system or PHP
The date that can be saved under a 64-bit system is 21 times times the current age of the universe-29.2 billion years. So it is not affected by this vulnerability.
How to detect
How to know if your system receives the impact of this vulnerability. Very simple, use strtotime directly to convert a date greater than January 19, 2038 03:14:07. or use the DATE function to convert a time stamp greater than 2147454847 to a date.
Here is a concrete demonstration
Method One
echo Date ("Y-m-d h:i:s", 2556115199);
Above results if return 2050-12-31 23:59:59 Then there is no problem. If it returns 1914-11-25 09:31:43 then it will be affected.
Method Two
Var_dump (Strtotime ("2050-12-31 23:59:59"));
The above result is normal if it returns 2556115199. If it returns false, it will also be affected.
Solution Solutions
Programme I
The replacement system and PHP are all 64-bit. It costs a lot, but it can solve the problem permanently.
Programme II
A function datetime is provided after the PHP5.2 version to temporarily resolve the problem.
1. Date string converted to timestamp $obj = new DateTime ("2050-12-31 23:59:59"), Echo $obj->format ("U"); 2556115199//2, timestamp converted to date string $obj = new DateTime ("@2556115199"); Write an @ sign $timezone = Timezone_open (' Asia/hong_kong ') before the time stamp here. Set time zone $obj->settimezone ($timezone); echo $obj->format ("y-m-d h:i:s"); 2050-12-31 23:59:59//and DateTime can have other gameplay $obj = new DateTime ("2050-12-31 23:59:59"); Echo $obj->format ("Y/m/d h:i:s "); Enter the time string in a different way 2050/12/31 23:59:59
Manipulating dates through DateTime classes is not affected by the y2k38 vulnerability, and can be supported up to December 31, 9999