PHP环境时区设置成Asia/Chongqing导致的一个bug

        得到某个时间戳所对应的日期的0时在这边的数据统计中经常用到，如得到1409144737（2014/8/27 21:5:37）的0时1409068800（2014/8/27 0:0:0），可用的方法也比较多，在这里介绍常用的三种： 
     1.mktime函数方式 
  

Java代码  

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函数方式 
    

Java代码  

1. var_dump(date('Y-m-d H:i:s',strtotime(date('Y-m-d 00:00:00',$time))));  

     
       因为上面两种方式调用多个函数得到结果，执行有点缓慢，效率不高，所以通过规律找到另一种方式，整除的方式。原理就是通过整除计算出今天已经过去的秒数,在计算过程中需要+8个小时，因为我们为东八区，比$time表示的实际秒数多8个小时。 
     3.整除方式 

Java代码  

1. var_dump(date('Y-m-d H:i:s',$time - ($time+8*60*60)%86400));  

通过执行10W次调用，以上三种方式分别花费30s、50s、14s，第三种方式效率还是蛮OK的。 

但是上线一段时候，测试提给我们一个bug，就是如果选择1975年的某时间戳会出现日期错误的bug，然后我们重现了这个bug 

    

Java代码  

1. $time = 321001200;//1980/3/4 15:0:0  
2.      var_dump(date('Y-m-d H:i:s',$time - ($time+8*60*60)%86400));  

      输出结果竟然是：1980-03-03 23:00:00，其他两种方式皆是正确的1980-03-04 00:00:00 
后来发现只在1980年5月以后的结果是正确的，而之前的都少了一个小时； 然后我看查看PHP的配置date.timezone = Asia/Chongqing，当换成PRC的时候，所有时间段都正确 ；至此bug其实解决了，让运维把线上600机子的配置进行修改，但是为啥呢，我们推测1980年的5月一定发生了啥事情吧，然后都按照GMT+8计算了