在 WordPress 中使用 DateTime::createFromFormat() 创建时间对象时，若未显式传入时区参数，会默认使用服务器本地时区（而非 WordPress 设置的时区），导致生成的时间戳与预期不符；本文详解问题根源及标准化解决方案。
在 wordpress 中使用 `datetime::createfromformat()` 创建时间对象时，若未显式传入时区参数，会默认使用服务器本地时区（而非 wordpress 设置的时区），导致生成的时间戳与预期不符；本文详解问题根源及标准化解决方案。
在 WordPress 开发中，常需生成「每天 21:00」这类固定时刻的 Unix 时间戳（如用于定时任务、预约逻辑或日志标记）。但如示例所示，当 WordPress 时区设为 Europe/Paris（UTC+2），而服务器默认时区为 UTC 或其他值时，以下代码会产生偏差：
$timezone = wp_timezone(); // Europe/Paris (UTC+2)
$start = DateTime::createFromFormat('G:i', '21:00'); // ❌ 未指定时区 → 使用 date_default_timezone_get()
$start1 = $start->getTimestamp(); // 得到的是 UTC 21:00 的时间戳 → 对应巴黎时间 23:00
根本原因在于：DateTime::createFromFormat() 的第三个参数 $timezone 是可选的，若省略，PHP 将回退至 date_default_timezone_get() 返回的服务器默认时区（通常为 UTC 或 America/Chicago 等），而非 WordPress 主动配置的时区。这导致 21:00 被解析为「服务器时区下的 21:00」，再转换为 Unix 时间戳后，与 Europe/Paris 下的 21:00 相差 2 小时。
✅ 正确做法是显式传入 WordPress 时区对象：
$timezone = wp_timezone(); // DateTimeZone object for Europe/Paris
// ✅ 正确：指定时区，确保 '21:00' 解析为巴黎时间 21:00
$start = DateTime::createFromFormat('G:i', '21:00', $timezone);
if (!$start) {
throw new InvalidArgumentException('Invalid time format');
}
$timestamp = $start->getTimestamp(); // 例如：1661446800 → 2022-08-25 21:00:00 CEST
// 验证输出（推荐用于调试）
echo $start->format('Y-m-d H:i:s T'); // 输出：2022-08-25 21:00:00 CEST
echo "\nUnix timestamp: " . $timestamp;
⚠️ 注意事项：
- 不要混用
strtotime()（如strtotime('21:00')）：它完全忽略$timezone参数，始终基于服务器时区解析，且不支持DateTimeZone对象； -
wp_date('U', $ts, $timezone)中的$timezone仅影响格式化输出，不改变$ts的原始值，因此不能用于修正时间戳生成逻辑； - 若需每日动态生成（如明天 21:00），建议用
modify()方法：$start = new DateTime('today 21:00', $timezone); $start->modify('+1 day'); // 明天 21:00 $tomorrow21 = $start->getTimestamp();
总结：始终将 wp_timezone() 作为 DateTime::createFromFormat() 的第三个参数；避免依赖隐式时区行为；通过 format() 方法验证时区与时间是否符合业务预期——这是保障时间逻辑跨环境一致性的关键实践。
