php 8.2 的 strtotime() 本身不“不准”，问题根源在于系统时间漂移、时区配置错误或输入字符串歧义；需检查 ntp 同步、正确处理时区、避免拼接无时区标识的时间字符串。
PHP 8.2 的 strtotime() 本身不会因版本升级突然“不准”，真正出问题的通常是底层系统时间或时区环境被悄悄破坏了。
系统时间漂移会导致 strtotime() 解析偏移
如果服务器本地时间比真实 UTC 慢或快几分钟（常见于未启用 NTP 同步的虚拟机、Docker 容器或老旧物理机），strtotime() 所有相对计算都会跟着偏。比如：strtotime('now')、strtotime('+1 day')、甚至 strtotime('2026-04-19') 都可能返回错误时间戳——不是函数错了，是它信任的“现在”本身就是错的。
- 用
date命令直接查系统时间：date -u（UTC）和date（本地）对比，看是否一致 - 检查是否启用 NTP：
timedatectl status，关注System clock synchronized: yes和NTP service: active - Docker 容器默认不继承宿主机时钟，需挂载
/etc/localtime或使用--privileged+systemd-timesyncd
strtotime('Y-m-d 00:00:00') 返回 8 点而非 0 点的真相
这不是 PHP 8.2 特有 bug，而是时区解析歧义在宽松字符串格式下的必然结果。当你写 strtotime(date('Y-m-d') . ' 00:00:00')，PHP 实际收到的是类似 "2026-04-19 00:00:00" 这样的字符串。如果当前时区是 Asia/Shanghai（UTC+8），而字符串里没带时区标识，strtotime() 会按“本地时间解释该字符串”，再转成 UTC 时间戳——所以你得到的是当天 0 点本地时间对应的 UTC 时间戳，date('Y-m-d H:i:s', $ts) 再格式化回来就显示为 08:00:00（因为又转回本地时区）。
- 正确做法：用
strtotime(date('Y-m-d'))，不拼时间部分，它隐式按当日 00:00:00 本地时间处理，且无歧义 - 更可靠写法：
new DateTime(date('Y-m-d'))->getTimestamp()，明确构造日期对象 - 绝对避免：
strtotime('2026-04-19 00:00:00 GMT')和strtotime('2026-04-19 00:00:00 UTC')混用，大小写、空格、缩写都影响解析
PHP 8.2 中 strtotime() 的兼容性变化点
PHP 8.2 并未修改 strtotime() 的核心逻辑，但收紧了部分边缘行为的容错，让原本“侥幸通过”的错误输入更快暴露：
- 传入
null、array或含中文字符的字符串（如"2026年4月19日"）会更大概率返回false，而不是静默返回 1970-01-01 时间戳 - 无效日期如
'2026-02-30'不再自动溢出为 2026-03-02，而是直接返回false（取决于编译时 glibc 版本） - 对
24:00:00这类非标准时间字面量的支持被移除，此前某些系统会接受，现在一律失败
真正要盯住的不是 strtotime() 函数本身，而是它运行的土壤：系统时间是否可信、时区是否显式设置、输入字符串是否无歧义。一旦这三个点松动，再老练的日期逻辑也会在某个凌晨三点悄然失效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
