PHP DateTime构造时未显式指定时区会导致后续转换不可靠，应始终传入DateTimeZone对象；解析无时区字符串需补全时区；避免依赖date_default_timezone_set()；setTimezone()不改变时间戳仅改变上下文；存储推荐DATETIME+UTC，禁用时区缩写解析。
PHP DateTime 构造时没设时区，后续转换就不可靠
PHP 的 DateTime 对象默认使用系统时区（date.timezone 配置值），一旦构造时不显式指定，哪怕只差一秒，后续调用 setTimezone() 也可能产生意外偏移——尤其是处理跨日、夏令时切换或 UTC 基准时间时。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 始终在构造时传入
DateTimeZone对象，而不是依赖 ini 设置：$dt = new DateTime('2024-03-10 02:30:00', new DateTimeZone('America/New_York')); - 若从字符串解析且无时区信息（如
"2024-03-10 15:20"），必须明确补上时区，否则 PHP 会按本地时区解释，不是“无时区”，而是“隐含本地时区” - 避免用
date_default_timezone_set()全局切换来“修正”，它影响整个请求生命周期，多线程/协程环境下极易冲突
用 setTimezone() 转换时区，但结果时间不对
常见错误是把“显示格式化”和“时区转换”混为一谈：调用 setTimezone() 后再用 format('Y-m-d H:i')，看起来变了，但本质是同一时刻在不同时区的表达；而如果误以为它修改了“原始时间值”，就会在存储或比较时出错。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
-
setTimezone()不改变时间戳（Unix timestamp），只改变时区上下文。可通过getTimestamp()验证前后是否一致 - 需要存数据库或做计算，优先转成 UTC 时间戳或
DateTime对象（带UTC时区）：$utc = clone $dt;<br>$utc->setTimezone(new DateTimeZone('UTC')); - 注意夏令时边界：比如
America/New_York在 3 月第二个周日凌晨 2 点跳到 3 点，这个“2:30”在本地不存在，DateTime会静默调整为 3:30，不是报错
DateTime::createFromFormat() 解析带时区缩写的字符串很危险
像 "2024-03-10 14:30:00 EST" 这类字符串，EST 是缩写，PHP 不保证能正确映射到 America/New_York，尤其在不同系统（Linux/macOS/Windows）或 ICU 版本下行为不一致；更糟的是，PST、GMT、UTC 等缩写可能被错误识别或忽略。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 禁用缩写解析，改用带 UTC 偏移的格式（如
"2024-03-10 14:30:00 -0500"），用DateTime::createFromFormat('Y-m-d H:i:s O', $str) - 若必须处理缩写，先手动替换为标准时区标识：
$str = str_replace(['EST', 'EDT'], ['America/New_York', 'America/New_York'], $str);
再交给DateTime构造 - 永远不要信任客户端传来的时区缩写，前端应传 ISO 8601 格式（含
Z或+00:00）或明确的时区名称
MySQL 存储时间用 DATETIME 还是 TIMESTAMP？PHP 怎么配合
TIMESTAMP 类型在 MySQL 中自动转为 UTC 存储、查询时转回会话时区，看似省事，但实际容易和 PHP 的时区逻辑打架：PHP 默认用系统时区解释字符串，而 MySQL 会话时区可能不同，导致读写不一致。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 统一用
DATETIME存储，所有时间以 UTC 为准（PHP 中先转成 UTC 再存），避免任何隐式转换 - 连接 MySQL 时显式设置时区为 UTC：
$pdo = new PDO($dsn, $user, $pass, [<br> PDO::MYSQL_ATTR_INIT_COMMAND => "SET time_zone = '+00:00'"<br>]);
- 读取后，用
new DateTime($row['created_at'], new DateTimeZone('UTC'))构造，再按需转目标时区，不依赖 MySQL 自动转换
