A bug caused by setting the time zone of the PHP environment to Asia/Chongqing

A bug caused by setting the time zone of the PHP environment to AsiaChongqing ???? It is often used to obtain the 0 hour of the date corresponding to a timestamp in the data statistics here. For example, we can obtain the 0 hour 1409144737 (201482721: 0: 0: 1409068800: 37) of 20148270 (: 0: 0). There are many available methods. here we will introduce three commonly used methods :?????? 1. mktime function method ?? A bug caused by setting the time zone of the PHP environment to Asia/Chongqing

? ? ? ? It is often used to obtain the 0 hour of the date corresponding to a timestamp in the data statistics here. For example, we can obtain the 0 hour 1409144737 () of 1409068800 ), there are also many available methods. here we will introduce three common methods :?
?????1. mktime function method?
??

Java code ??

1. $ Time? = 1409144737 ;??
2. ??? Var_dump (date ('Y-m-d? H: I: S', mktime (0, 0, 0, date ('M', $ time), date ('D', $ time), date ('Y ', $ time ))));??

?????2. strttime function method?
????

Java code ??

1. Var_dump (date ('Y-m-d? H: I: S', strtotime (date ('Y-m-d? 00:00:00 ', $ time ))));??

?????
? ? ? ? Because the above two methods call multiple functions to get the result, the execution is slow and the efficiency is not high, so we can find another method by regular division. The principle is to calculate the number of seconds that have passed today through the division. it takes more than 8 hours for the calculation process, because we are in the GMT + 8, eight hours more than the actual number of seconds represented by $ time .?
?????3. division method?

Java code ??

1. Var_dump (date ('Y-m-d? H: I: S', $ time? -? ($ Time + 8*60*60) % 86400 ));??

By executing 10 million calls, the above three methods are 14 s, 50 s, and 30 s respectively. The third method is quite efficient .?

However, when we went online for a while, the test gave us a bug, that is, if a timestamp on January 1, 1975 is selected, there will be a date error bug, and then we reproduce this bug?

????

Java code ??

1. $ Time? =? 321001200; // 1980/3/4? Am ??
2. ????? Var_dump (date ('Y-m-d? H: I: S', $ time? -? ($ Time + 8*60*60) % 86400 ));??

? ? ? The output result is 23:00:00. The other two methods are correct 00:00:00?
Later, it was found that the result was correct only after May 1980, and the previous result was less than an hour ;? Then I will check the PHP configuration date. timezone = Asia/Chongqing. when it is changed to PRC, all the time periods are correct. so far, the bug has actually been solved, so that the O & M personnel can modify the configuration of the online 600 hosts, but why, let's guess what happened in 1980, May 1, and then it's all calculated based on GMT + 8?