PHP DateTime 时区必须显式设置，否则默认 UTC 导致时间偏差；构造、格式化、计算、存储各环节均需严格管控时区，推荐统一用 UTC 存储并按需转换。
DateTime 构造失败：时区不设就出错
PHP 的 DateTime 默认依赖系统时区，但一旦没显式设置，new DateTime() 可能返回意外结果，尤其在 CLI 环境或跨服务器部署时。比如 date_default_timezone_set('Asia/Shanghai') 没调用，new DateTime('2024-01-01') 会按 UTC 解析，再转本地显示，时间差 8 小时是常态。
- 始终在初始化前设时区：
date_default_timezone_set('Asia/Shanghai')或在php.ini中配date.timezone = Asia/Shanghai - 更稳妥的做法是构造时直接传时区对象：
new DateTime('2024-01-01', new DateTimeZone('Asia/Shanghai')) - 别依赖
ini_get('date.timezone')判断——它可能为空，但DateTime不报错，只静默 fallback 到 UTC
format() 输出不准：时区没切就格式化
format() 只负责把内部时间戳按当前时区转成字符串，它不改变时间本身。常见错误是：构造时用了东八区，后续调 setTimezone(new DateTimeZone('UTC')) 忘了调，就直接 format('Y-m-d H:i:s') ——结果还是东八区时间，不是你想要的 UTC 字符串。
- 格式化前务必确认当前对象的时区：
$dt->getTimezone()->getName() - 需要输出 UTC 时间？先切时区：
$dt->setTimezone(new DateTimeZone('UTC'))，再format() - 注意
format('U')返回的是 Unix 时间戳（秒级），与时区无关；但format('c')或format('Y-m-d\TH:i:sP')会带时区偏移，必须提前 set
日期计算翻车：add() 和 modify() 行为不同
add() 按日历单位加（如加 1 个月 = 到下月同日），而 modify() 是字符串解析式操作（如 modify('+1 month') 行为类似 add()，但 modify('last day of next month') 更灵活）。最坑的是：2 月 30 日这种不存在的日期，add(new DateInterval('P1M')) 会自动滚到 3 月 2 日，而不是报错。
- 要严格校验日期有效性，别只靠
add()后检查format('t')——它已经滚了 - 做“月末最后一天”逻辑，优先用
modify('last day of this month')，比add('P1M')->modify('first day of previous month')直观且不易错 -
DateInterval的P1M不等于 30 天，它依赖日历；需要固定天数请用P30D并确认是否真要跳过月份逻辑
与 MySQL 时间交互：NOW() 和 PHP DateTime 时区对不齐
MySQL 的 NOW() 返回的是服务器时区时间，不是 UTC；而 PHP 的 DateTime 如果设的是 Asia/Shanghai，两者表面一致，但一旦数据库时区被改成 +00:00 或应用部署到海外服务器，$dt->format('Y-m-d H:i:s') 插入后查出来就差 8 小时。
- 统一用 UTC 存储：PHP 侧构造后先
setTimezone(new DateTimeZone('UTC'))再插入；读取后按需转本地时区 - 别信
SELECT NOW()返回值——它受time_zone会话变量影响，可用SELECT @@session.time_zone查 - PDO 插入时，用
$pdo->prepare("INSERT INTO t (ts) VALUES (?)")+$dt->format('Y-m-d H:i:s')前确保时区已切，否则字符串里就是错的
时区不是个开关，是贯穿构造、计算、格式化、存储每一步的隐含状态。漏掉一次 setTimezone()，可能要花半小时查日志才能定位到哪行 format() 出了问题。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
