Home  >  Article  >  Backend Development  >  How to solve the error when converting dates beyond 2038 in PHP

How to solve the error when converting dates beyond 2038 in PHP

小云云
小云云Original
2018-02-10 13:23:501927browse

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!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn