夏令时与重复事件存储方案咨询：类谷歌日历系统优化需求

看起来你之前的问题核心在于时区处理不严谨（固定偏移量忽略夏令时），以及重复事件的UTC存储/计算效率问题。结合Google Calendar的设计思路，给你一套更可靠的方案：

第一步：修复时区存储问题 #

之前存固定偏移量（比如-04:00）的最大问题是无法自动适配夏令时切换（比如EST和EDT其实是America/New_York时区的不同时段）。正确的做法是：

• 存储IANA时区标识符（比如America/New_York、America/Chicago），而不是固定偏移量或缩写。
• PHP的DateTime和DateTimeZone类原生支持这些标识符，能自动处理夏令时的时间偏移变化。

第二步：重复事件的高效处理方案 #

针对“无法存储所有UTC值”的问题，有两种优化思路，按需选择：

思路1：基于规则实时计算（推荐无限重复场景） #

不需要预存所有UTC时间，而是每次cron运行时，根据事件的本地时间规则、时区、重复规则实时计算是否需要触发通知。这种方式更灵活，尤其适合无限重复的事件：

核心逻辑：

1. cron以UTC时间每15分钟运行一次，先获取当前UTC时间。
2. 遍历所有需要检查的事件，将当前UTC时间转换为事件所属时区的本地时间。
3. 根据事件的重复规则（每日、工作日、每月第2天等），计算出下一次应该触发的本地时间。
4. 将这个本地时间转换回UTC，判断是否落在当前cron的检查窗口内（比如过去15分钟到现在），如果是则发送通知。

PHP代码示例（以“每月第2天09:00”为例）：

// 从数据库取出的事件数据
$event = [
    'local_time' => '09:00',
    'timezone_id' => 'America/New_York',
    'repeat_rule' => 'monthly_2nd',
    'repeat_count' => null, // 无限重复
    'current_repeat' => 0 // 已触发次数
];

// 当前UTC时间
$nowUtc = new DateTime('now', new DateTimeZone('UTC'));
// 事件所属时区
$eventTz = new DateTimeZone($event['timezone_id']);
// 当前事件时区的本地时间
$nowLocal = $nowUtc->setTimezone($eventTz);

// 计算下一次触发的本地时间
$nextLocal = clone $nowLocal;
// 设置日期为当月2日，时间为指定的本地时间
[$hour, $minute] = explode(':', $event['local_time']);
$nextLocal->setDate($nextLocal->format('Y'), $nextLocal->format('m'), 2);
$nextLocal->setTime((int)$hour, (int)$minute);

// 如果当月2日已过，自动切换到下月2日
if ($nextLocal < $nowLocal) {
    $nextLocal->modify('+1 month');
}

// 转换回UTC时间，判断是否在当前cron周期内（过去15分钟到现在）
$nextUtc = $nextLocal->setTimezone(new DateTimeZone('UTC'));
$cronWindowStart = clone $nowUtc;
$cronWindowStart->modify('-15 minutes');

if ($nextUtc >= $cronWindowStart && $nextUtc <= $nowUtc) {
    // 执行发送通知逻辑
    sendEventNotification($event);

    // 如果是有限重复，更新已触发次数；无限重复则无需额外操作（下次计算会自动取下月）
    if ($event['repeat_count'] !== null) {
        $newRepeatCount = $event['current_repeat'] + 1;
        if ($newRepeatCount >= $event['repeat_count']) {
            // 重复次数耗尽，标记事件为已结束
            markEventAsCompleted($event['id']);
        } else {
            updateEventRepeatCount($event['id'], $newRepeatCount);
        }
    }
}

思路2：优化的“下一次UTC”存储（适合性能敏感场景） #

如果担心全量计算的性能，可以结合规则存储和“下一次UTC”字段，但要基于时区标识符计算，而非固定偏移量：

1. 存储事件的本地时间规则、时区标识符、重复规则，同时存储next_utc（下一次触发的UTC时间）。
2. cron运行时，直接检查next_utc是否在当前周期内，触发后根据规则计算再下一次的UTC时间并更新数据库。
3. 计算下一次时间时，必须使用事件的时区标识符转换，确保夏令时切换时时间正确。

关键注意事项 #

• 永远用IANA时区标识符：不要用EST/EDT这类缩写，它们不唯一且无法自动处理夏令时。PHP支持的时区列表可以用DateTimeZone::listIdentifiers()查看。
• 所有时间判断基于UTC：cron运行在UTC时间下，避免本地时区干扰导致的触发错误。
• 复杂规则的简化处理：如果需要支持每周多日、每月最后一个工作日这类复杂规则，可以实现RFC 5545标准的重复规则逻辑，减少自己造轮子的错误。
• 夏令时测试：一定要测试夏令时切换前后的事件触发情况，比如3月和11月的时间变化，确保计算逻辑正确。

内容的提问来源于stack exchange，提问作者Jaimin MosLake