date()函数仅接受int型时间戳，依赖服务器时区配置，易因时区未设或传入字符串导致时间错误；推荐用DateTime类解耦时间、时区与格式，确保跨时区转换安全可控。

date() 函数是 PHP 里最常用、也最容易出错的日期格式化入口

直接用 date() 就能格式化当前时间，但它的行为高度依赖服务器时区设置，且不接受任意时间戳以外的输入——比如你传个字符串进去，它会静默转成 1970 年 1 月 1 日。很多“时间不对”的问题，根源就在这儿。

• 只接收 int 类型的时间戳（秒级），传 float 或字符串会触发警告或返回错误结果
• 默认使用 date.timezone 配置，没设的话会报 Warning: date(): It is not safe to rely on the system's timezone settings
• 想格式化非当前时间？得先用 strtotime() 或 DateTime 转成时间戳，不能跳步
• 示例：date('Y-m-d H:i:s', strtotime('2023-10-05 14:30:00')) —— 这才是安全写法；单独 date('Y-m-d', '2023-10-05') 会输出 1970-01-01

需要处理用户输入或复杂时区时，别硬刚 date()/strtotime()，用 DateTime 类

DateTime 是 PHP 5.2+ 的标准解法，它把时间、时区、格式三者解耦，避免了 date() + strtotime() 组合里一堆隐式转换和时区污染。

• strtotime() 解析模糊（如 "last Monday" 在不同 PHP 版本结果可能不同），DateTime 更可控
• 时区可绑定到对象本身：$dt = new DateTime('2023-10-05 14:30:00', new DateTimeZone('Asia/Shanghai'));
• 格式化统一走 format() 方法：$dt->format('Y-m-d H:i:s')，和 date() 的格式字符完全兼容
• 跨时区转换简单：$dt->setTimezone(new DateTimeZone('UTC'));，不用手动加减秒数

格式字符串里这些字符最容易记混或误用

PHP 的日期格式符看着像直觉，其实有几个关键陷阱：大小写敏感、语义差异大、部分字符在不同上下文表现不一。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

• Y（4 位年份） vs y（2 位）：用错会导致 2023 变成 23，后续计算或存储出问题
• H（24 小时制） vs h（12 小时制）：没配 A 或 a 的话，h 会默认为上午，13:00 变成 01:00
• i 是分钟，s 是秒，u 是微秒（不是毫秒！），date('u') 永远返回 000000 —— 因为 date() 不支持微秒精度
• 要输出文字内容（比如“星期三”），得用 l（小写 L）或 D，但它们依赖 setlocale()，而 date() 本身不读 locale，得配合 strftime() 或 IntlDateFormatter

线上环境必须检查 date.timezone 配置，否则本地能跑线上崩

开发机常默认设了 date.timezone，但生产服务器（尤其 Docker 容器或共享主机）很可能没设，导致所有 date() 和 DateTime 构造失败或返回 GMT 时间。

立即学习“PHP免费学习笔记（深入）”；

• 检查方式：echo date_default_timezone_get();，不是看 phpinfo() 里写的，而是运行时实际生效的值
• 临时修复：在脚本开头加 date_default_timezone_set('Asia/Shanghai');，但只是补丁，不是方案
• 根治方法：在 php.ini 里设 date.timezone = Asia/Shanghai，或 Docker 中通过 ENV TZ=Asia/Shanghai + ln -snf /usr/share/zoneinfo/$TZ /etc/localtime 同步系统时区
• 注意：date_default_timezone_set() 影响的是整个请求生命周期，如果框架或 Composer 包里提前调用了 date()，再设就晚了

事情说清了就结束。真正麻烦的从来不是函数怎么写，而是时间戳来源是否可靠、时区是否全程一致、格式字符串有没有被复制粘贴错大小写。