在PHP应用运行过程中，时间相关函数返回的结果如果和预期不符，最常见的原因是系统没有设置正确的时区。无论你是用date函数格式化当前时间，还是用strtotime解析字符串，底层都会参考PHP运行时认定的时区基准。一旦这个基准是UTC而非东八区，页面上展示的时间就会整体偏移八小时，在日志、订单时间、定时任务等场景中引发一连串错误。
一、为什么时区会显示不对
PHP在安装完成后，很多发行版默认的php.ini中date.timezone这一项是被注释掉的，或者显式写成了UTC。根据PHP官方行为，当该参数未设置时，部分版本会抛出警告，部分版本则静默使用UTC。中国所处的时区为东八区，与UTC存在八小时时差，因此直接调用date('Y-m-d H:i:s')就会拿到比北京时间晚八小时的结果。
除了配置缺失，另一种情况是修改了php.ini却未重启服务。例如使用php-fpm时，修改配置后必须重启php-fpm进程，否则旧的主进程仍持有原来的时区设定。命令行PHP和Web PHP有时还会加载不同的ini文件，这也是明明改了配置但页面依然错误的高发原因。
二、修改php.ini中的date.timezone参数
最彻底的解决方式是在php.ini中写明时区。你需要先通过phpinfo()或者命令行php --ini找到当前生效的配置文件路径，然后用编辑器打开它，搜索date.timezone。
将该行修改为如下内容，注意去掉前面的分号注释符：
; 修改前可能是 ; date.timezone = ; 修改后 date.timezone = "Asia/Shanghai"
保存文件以后，根据运行模式执行对应重启操作。若是Apache模块方式，重启Apache；若是php-fpm，则重启php-fpm服务。重启完成后，新建一个测试脚本验证。
<?php
echo date('Y-m-d H:i:s');
// 若输出接近当前北京时间，说明配置生效
?>
三、临时在代码中指定时区
当你没有权限修改服务器上的php.ini，或者只希望某个独立脚本使用特定时区，可以在代码开头调用date_default_timezone_set函数。这种方式只影响当前请求生命周期，不会干扰全局。
<?php
date_default_timezone_set('Asia/Shanghai');
echo date('H:i:s');
?>
这种写法虽然方便，但在大型项目中容易造成时区不统一。比如定时任务脚本设置了时区，而Web接口没有设置，写入数据库的时间就会错乱。因此临时方案只建议用于本地调试或一次性工具，长期运行的产品仍应以php.ini配置为准。
四、如何确认当前时区是否生效
排查问题时，最直观的办法是查看phpinfo输出。在浏览器访问包含phpinfo()的页面，搜索date.timezone，能看到Local Value和Master Value。如果二者不一致，说明代码或目录级配置覆盖了全局。
命令行下也可以使用如下指令快速检查：
php -i | grep "date.timezone"
若返回为空或者显示UTC，就证明配置文件没有被正确加载，需要核对php.ini路径以及服务重启状态。通过这种分层确认，基本可以定位九成以上的PHP时区异常。
五、常见时区标识符对照
PHP依赖操作系统提供的时区数据库，常用中国相关标识符如下。写错拼写会导致函数报错，因此建议直接复制使用。
| 地区 | 时区标识符 |
|---|---|
| 北京时间 | Asia/Shanghai |
| 香港 | Asia/Hong_Kong |
| 台北 | Asia/Taipei |
| 东京 | Asia/Tokyo |
设置时区后，所有基于时间戳的运算都会以该时区解释。如果你的应用涉及多国家用户，更合理的做法是存储UTC时间，仅在展示层按用户所在时区转换，而不是全局写死单一时区。
六、避坑小结
不要轻信某些教程里写的用putenv设置TZ环境变量来替代date.timezone，在多线程模型下这种方式并不可靠。也不要在每次调用date时都动态计算时区，这会带来不必要的性能损耗。
统一在php.ini中声明date.timezone，配合重启和phpinfo验证，是解决PHP时区显示不对最稳妥的路径。当架构演进到跨时区业务时，再引入UTC存储与展示层转换的方案，就能在稳定性和扩展性之间取得平衡。
PHPdate_timezonephp_ini修改时间：2026-08-02 21:24:29