PHP一个函数BUG——strtotime()

发表于   |   分类于 技术宅   |   0 条评论  
前两天收到用户反馈，PT站评论一次后，第二次评论时会提示：禁止滥发评论，请在******秒之后评论，我感到很奇怪，PT站恢复之后所有数据都是和原来的一模一样，为什么现在出现这个Bug呢，我也不记得有这个设置，而且上个月也没有收到反馈。查看源码： 看了下表单，评论是POST到comment.php这个文件上了，打开这个文件，找到时间限制的关键代码： 
if (get_user_class() < $commanage_class) {
			if (strtotime($CURUSER['last_comment']) > (TIMENOW - 10))
			{
				$secs = 10 - (TIMENOW - strtotime($CURUSER['last_comment']));
				stderr($lang_comment['std_error'],$lang_comment['std_comment_flooding_denied']."$secs".$lang_comment['std_before_posting_another']);
			}
		}
很容易看懂这个逻辑，10秒之内禁止发布第二条评论，看样子肯定是if的条件判断出了问题，于是我将strtotime($CURUSER['last_comment']和TIMENOW打印出来看了一下，strtotime($CURUSER['last_comment']打印出来的时间戳转换之后是明天的日期，果然是这个问题，首先我是怀疑数据库的问题，于是查询数据库，看了下user表的last_comment字段，结果没有问题，数据库日期是正常的。不过我当时感觉很疑惑，为什么麦田团队保存日期不用int类型的时间戳而用的是String，保存的日期是2014-12-05 19:20:31这样的，看到这个当时我还开玩笑说是机房有鬼，生前还是个程序员，玩笑归玩笑，继续排查。 继续echo $CURUSER['last_comment']，得到的值是正确的，就是数据库的那个值，基本上确定是strtotime这个函数的问题了，在服务器上新建一个time.php测试一下 

得到一个时间戳，然后转化一下，结果令我感到很差异，竟然是2014-12-06，后来经朋友提示是时区的问题，在全局配置文件中添加


貌似是时区的问题，以前用的lnmp，没有出现这个问题，看来lnmp在本地化上做的还是不错的，这个函数计算时间的时候是按每个月30天算的，这个月是12月，有31天，所以就出现了问题o(╯囧╰)o