PHP IntlCalendar 怎样判断夏令时切换后的本地时间

如果业务只保存“2026-10-25 01:30”这样的本地时间，就很难判断它对应哪个实际瞬间。PHP 的 IntlCalendar 更适合处理这类边界：先把时间看成一个绝对 instant，再配合 ICU 时区读取本地字段，最后用 inDaylightTime() 判断该 instant 是否处于夏令时。

核心顺序是：先确定绝对时刻，再设置目标时区，最后读取字段和夏令时状态。遇到春季跳过或秋季重复的墙上时间，还要显式选择 WALLTIME_FIRST、WALLTIME_LAST 或 WALLTIME_NEXT_VALID。

先把绝对时刻和本地字段分开

绝对时刻可以理解为时间线上的一个点，通常以 UTC 毫秒时间戳表示；本地字段则是某个时区把这个点展示成的年、月、日、时、分、秒。夏令时切换时，变化的是偏移量和本地显示，不应该把它们混成一个字符串。

IntlCalendar::setTime() 接受从 Unix 纪元开始计算的毫秒数，setTimeZone() 改变日历使用的时区。后者会保留日历代表的 instant，但本地字段会随时区重新计算。

用 inDaylightTime 判断当前 instant

下面的例子把一个 UTC 秒时间戳转换成毫秒，创建一个公历日历，再读取纽约时区下的本地字段和夏令时状态。示例中的日期只用于演示调用关系，生产代码应从业务事件或持久化的 UTC instant 得到时间。

setTime($utcSeconds * 1000.0);

// 这里判断的是这个 instant 在目标时区是否处于夏令时。
$isDst = $calendar->inDaylightTime();
$local = [
    'year' => $calendar->get(IntlCalendar::FIELD_YEAR),
    // 月份字段从 0 开始，展示给用户时要加 1。
    'month' => $calendar->get(IntlCalendar::FIELD_MONTH) + 1,
    'day' => $calendar->get(IntlCalendar::FIELD_DATE),
    'hour' => $calendar->get(IntlCalendar::FIELD_HOUR_OF_DAY),
];

var_dump($isDst, $local);
?>

判断结果依赖两个输入：日历当前代表的 instant，以及日历当前使用的时区。只替换时区而不替换 instant，得到的结果才适合回答“同一事件在当地几点发生、当时是否处于夏令时”。

切换时区时保留同一个事件时间

有时需要把同一个事件分别显示给不同地区的用户。这时不要重新拼接本地日期字符串，而是先设置一次绝对时间，然后依次调用 setTimeZone()。每次切换后读取到的字段会改变，但 getTime() 对应的 instant 应保持一致。

setTime(strtotime('2024-07-01 12:00:00 UTC') * 1000.0);
$originalInstant = $calendar->getTime();

foreach (['America/New_York', 'Asia/Shanghai'] as $timezone) {
    // 只改变显示时区，不重新解释原来的时间点。
    $calendar->setTimeZone($timezone);
    $hour = $calendar->get(IntlCalendar::FIELD_HOUR_OF_DAY);
    $dst = $calendar->inDaylightTime() ? 'DST' : 'standard';

    echo $timezone, ': ', $hour, ':00 (', $dst, ")\n";
}

// 用 instant 做回归判断，避免时区切换误改事件本身。
var_dump($originalInstant === $calendar->getTime());
?>

需要注意，FIELD_MONTH 是从 0 开始的，而 FIELD_DATE 是月中的日。把字段拼成接口响应时，应统一处理月份偏移和时区标识，最好同时返回原始 UTC instant，避免消费者再次猜测。

春季跳过的本地时间怎样选策略

在正向调整时钟的切换点，一段本地墙上时间根本不存在。例如时钟从 01:59:59 直接跳到 03:00:00，02:30 不是一个真实发生过的本地时间。IntlCalendar 可以通过 setSkippedWallTimeOption() 设定遇到这类输入时的策略。

setLenient(true);

// 选择跳过区间的处理方式：取切换前、切换后或下一个有效时间点。
$calendar->setSkippedWallTimeOption(IntlCalendar::WALLTIME_NEXT_VALID);
$calendar->set(2013, 9, 27, 1, 30, 0);

// 读取最终 instant；字段是否被改写不能只靠原始输入字符串判断。
$resolvedMilliseconds = $calendar->getTime();
var_dump($resolvedMilliseconds, $calendar->getSkippedWallTimeOption());
?>

可选值是 WALLTIME_FIRST、WALLTIME_LAST 和 WALLTIME_NEXT_VALID。官方手册说明默认值为 WALLTIME_LAST；业务上更重要的是把选择写进约定，例如预约系统可以选择“切换后的第一个有效瞬间”，而报表导入则可能直接拒绝不存在的墙上时间。

秋季重复的本地时间怎样区分两次出现

在反向调整时钟的切换点，一段本地墙上时间会出现两次。两个“01:30”看起来相同，但它们对应不同的 UTC instant 和不同的偏移量。此时可用 setRepeatedWallTimeOption() 选择第一次出现或第二次出现。

setLenient(true);

// WALLTIME_FIRST 取重复本地时间的第一次出现，LAST 取第二次出现。
$calendar->setRepeatedWallTimeOption(IntlCalendar::WALLTIME_FIRST);
$calendar->set(2013, 9, 27, 1, 30, 0);

$firstOccurrence = $calendar->getTime();
$selectedPolicy = $calendar->getRepeatedWallTimeOption();

var_dump($firstOccurrence, $selectedPolicy);
?>

setRepeatedWallTimeOption() 只接受 WALLTIME_FIRST 或 WALLTIME_LAST。不要把这两个值当作“更早或更晚的字符串排序”，它们描述的是同一个本地字段在时钟回拨前后对应的不同 instant。

把时间边界落到业务数据模型

如果时间要进入数据库或消息队列，建议至少保存 UTC instant、业务时区标识和用户原始输入。展示层再用 IntlCalendar 生成本地字段。这样即使夏令时规则变化，也能重新解释同一个事件，而不是依赖一段无法唯一定位的本地字符串。

最后再检查三个容易遗漏的点：setTime() 的单位是毫秒；月份字段从 0 开始；intl 扩展和 ICU 能力要与部署环境一致。这样判断夏令时就不再是对字符串做猜测，而是对“instant + timezone”做明确计算。

相关问题

setTimeZone() 会把事件时间改掉吗？

它会保留日历代表的 instant，改变的是本地字段和时区解释。切换后可以用 getTime() 对比前后值，确认业务对象没有被重新解释。

inDaylightTime() 判断的是系统当前是否夏令时吗？

不是。它判断的是当前 IntlCalendar 对象所代表的 instant，在当前日历时区下是否处于夏令时。

为什么不能只保存本地日期时间字符串？

因为重复区间会出现两个相同的本地字符串，跳过区间则可能根本没有这个时间。至少补上时区和解析策略，已发生事件最好直接保存 UTC instant。