PHP DateInterval::createFromDateString 与 PT24H 的结果差异处理方法

PHP 里“加 24 小时”有两种容易混淆的写法：DateInterval::createFromDateString('24 hours') 和 new DateInterval('PT24H')。前者按日期时间组件推进，后者表达固定的 24 小时长度；遇到夏令时切换时，它们可能落在不同的本地时间。预约、账期要跟着日历走，超时和计费要跟着固定时长走，先把这个语义选对，再谈格式化。

先分清自然语言间隔和固定 24 小时

createFromDateString() 产生的是基于日期时间解析器的间隔，时间部分会递增或递减各个组件；PT24H 则是 ISO 8601 的固定时长写法。两者都能传给 DateTimeImmutable::add()，但“加法”背后的业务含义不同。

add($calendarInterval);
$fixedTime = $start->add($fixedInterval);

echo $calendarTime->format('Y-m-d H:i:s P'), PHP_EOL;
echo $fixedTime->format('Y-m-d H:i:s P'), PHP_EOL;
?>

这里的关键不是记住某个固定输出，而是看清两个间隔的来源。PHP 官方日期时间算术示例明确展示：在纽约时区的 DST 边界附近，组件递增与固定时长会产生不同的本地时间表现。图中的节点和连线是概念说明，不是本机运行截图。

用时区切换场景观察 add 的边界

在普通 UTC 测试里，两种写法很可能打印出相同的钟表时间，于是问题被掩盖。排查时要固定同一个 DateTimeImmutable、同一个 DateTimeZone 和同一个起点，再把 DST 切换日期纳入测试数据。

还要检查 $value->getTimezone()->getName()，确认对象没有在序列化、队列或数据库往返时悄悄换成默认时区。输出比较最好同时保留偏移量和时间戳：只看 Y-m-d H:i:s，可能把同一瞬时刻误判成两个事件。

按业务目标选择 API

可以把选择规则压缩成一句话：业务规则说“下一天、下一个月、每周某时刻”，使用组件或周期语义；业务规则说“从现在开始经过 86400 秒”，使用固定时长。DateTimeImmutable 适合在多层业务中传递，因为每次 add() 都返回新对象，能减少共享对象被意外改写的风险。

如果要遍历一组账单日，DatePeriod 表达“从起点按间隔产生日期”的意图更清楚；如果要做超时截止点，直接保存起始时间戳或明确的固定间隔，别把“自然日”误当作 24 小时。

发布前用四项清单检查结果

1. 起点是否包含明确的 DateTimeZone，而不是依赖服务器默认时区。
2. 间隔是自然日/自然小时，还是严格的固定秒数。
3. 测试数据是否覆盖 DST 切换、月末和跨日场景。
4. 日志是否同时记录格式化时间、偏移量和时间戳。

这四项能把“代码能跑”与“业务时间正确”分开。遇到跨地区系统，先写清时间语义，再决定 API，通常比事后补一个小时的偏移量更稳。

常见问题

createFromDateString('24 hours') 能替代 PT24H 吗？

不能默认替代。两者在没有时区切换的测试里可能看起来一样，但表达的是不同时间语义。

DateTimeImmutable::add() 会修改原对象吗？

不会。它返回新的 DateTimeImmutable，需要把返回值接住，否则计算结果不会进入后续变量。

为什么测试环境看不出差异？

常见原因是测试固定在 UTC 或没有覆盖 DST 边界。请使用明确的地区时区并把偏移量写进断言。