跨时区发布时间实操：UTC 基准与夏令时重复小时
复现 2026 年 1 月与 7 月纽约、上海、伦敦的时间换算，再区分纽约夏令时结束当天两次出现的 01:30。
先确认同一个 UTC 时刻，再展示各地发布时间。IANA 时区名称包含地区时间规则；单写“上午 9 点”，或沿用另一个季节的固定偏移，都不足以确定发布时刻。
本指南涉及工具
1. 核对 1 月的发布时刻
在时区转换器的 Date & Time 输入 2026-01-15 14:00，源时区填 UTC，目标时区填 America/New_York，再执行转换。目标应为 1 月 15 日 09:00，偏移 UTC−05:00（EST）；ISO 结果对应 2026-01-15T14:00:00.000Z。
保持源时间不变，把目标改为 Asia/Shanghai，应为 1 月 15 日 22:00，UTC+08:00；改为 Europe/London，应为 1 月 15 日 14:00，UTC+00:00。这三个本地时间表示同一个时刻，不是三个独立发布窗口。
2. 7 月重新换算，不沿用冬季偏移
只把源日期改为 2026-07-15，时间仍为 14:00、源时区仍为 UTC。纽约应为 10:00，UTC−04:00（EDT）；上海仍为 22:00，UTC+08:00；伦敦应为 15:00，UTC+01:00。
纽约和伦敦的季节性偏移已经改变。如果把 1 月的“纽约 09:00”直接复制到这个 7 月 UTC 计划，就会提前一小时。每个有具体日期的事件都应重新换算，通知中同时保留 UTC 时刻和具名本地时区。
3. 区分纽约重复出现的 01:30
保持源时区为 UTC，把 2026-11-01 05:30 转换到 America/New_York，结果为 11 月 1 日 01:30，UTC−04:00（EDT）。把源时间改为 06:30 UTC，目标仍是 01:30，但偏移变成 UTC−05:00（EST）。这两个事件实际相隔一小时。
当前转换器没有选择“重复小时的第一次或第二次”的控件。不要仅用“纽约 2026-11-01 01:30”作为发布计划的源时间。先向组织者确认 UTC 时刻或明确偏移，再按上面的方式从 UTC 转换。
4. 核对秒、毫秒和最终通知
1 月样例的 Unix 时间为 1768485600 秒，或 1768485600000 毫秒；7 月样例为 1784124000 秒，或 1784124000000 毫秒。如果看不到这些字段，在高级模式启用“输出 Unix 字段”，并确认接收 API 所需的单位。
可直接核对的通知写法是：发布开始于 2026-07-15T14:00:00Z；纽约 10:00 UTC−04:00；上海 22:00 UTC+08:00；伦敦 15:00 UTC+01:00。结束时刻或持续时间另行写明。浏览器可能使用不同的时区简称，应重点核对日期、时间和偏移。
5. 事件 ID 与事件顺序分开记录
UUID v7 可用来标识发布或回滚事件，其内嵌毫秒时间戳便于按时间组织数据，但不能建立跨服务的因果全序：不同机器的时钟可能有偏差，多个事件也可能发生在同一毫秒。
记录实际 UTC 事件时间、发布 ID、产生事件的服务，以及需要时序时所用的序号或父事件关系。把回滚明确关联到部署，比仅按两条 UUID 的大小推断关系更可靠。