Temporal通过显式建模时区、日历与瞬时点三层语义，解决夏令时切换导致的计费歧义问题：用ZonedDateTime锚定真实时刻，转Instant计算纳秒级时长，统一参考时区对齐日期，并主动标记异常时段供人工复核。
全球排班系统中，夏令时切换会导致同一本地时间在不同日期对应不同时长（比如“凌晨1点”在切换日可能重复或消失），若用传统 Date 处理计费逻辑，极易出现多扣、少扣、漏算工时等资损问题。Temporal 提案通过显式建模“时区+日历+瞬时点”三层语义，让计费校准可预测、可验证、可审计。
用 ZonedDateTime 锚定真实工作时刻，杜绝“时间漂移”
排班记录必须绑定具体时区下的真实时刻，而非字符串或本地时间。例如：员工在柏林当地时间 2026-10-26T02:30 开始值班——这个时间在夏令时结束日（钟表从 3:00 回拨至 2:00）属于“重复时段”，它不是模糊的，而是两个不同 UTC 时刻。
- ✅ 正确做法：用
Temporal.ZonedDateTime.from('2026-10-26T02:30+02:00[Europe/Berlin]')显式声明意图，并配合disambiguation: 'earlier'或'later'指定取哪个偏移（UTC+2 还是 UTC+1） - ❌ 错误做法：用
new Date('2026-10-26T02:30')解析，结果依赖浏览器当前时区且无法区分重复时间，后续计算直接失准
计费时长统一转为 Instant 计算，避开日历陷阱
所有工时、服务时长、超时费用都应基于绝对时间轴（UTC 纳秒）计算，而不是“加一天”“加一小时”这类日历操作——后者在夏令时边界会因偏移变化导致实际毫秒数偏差（±1 小时）。
- 排班起止时间先转成
Temporal.Instant：startZdt.toInstant()和endZdt.toInstant() - 差值用
.since()得到精确Duration：endInstant.since(startInstant)，单位为纳秒，不受任何时区规则影响 - 最终计费金额 =
duration.total({ unit: 'minutes' }) × 单价，全程无歧义
跨时区排班对齐需显式指定“参考时区”，不依赖用户本地设置
全球团队协作排班常需统一按某一时区（如运营中心所在时区）切分日期边界。若用 Date.toLocaleDateString() 或 getUTCDate() 切分，结果随客户端系统设置漂移，导致统计口径不一致。
- 定义标准参考时区（如
'Asia/Shanghai'），将所有员工的排班时间转为该时区下的ZonedDateTime - 用
.withPlainDate({ year, month, day })提取当日日历日期，再聚合工时 - 避免使用
new Date().getDate()或toLocaleString('zh', { timeZone: '...' })做日期归类——它们返回字符串，不可靠用于分组键
异常时段自动标记与人工复核机制
夏令时切换日本身是高风险节点。Temporal 可主动暴露问题，而非静默容错：
- 解析排班输入时，捕获
RangeError并检查是否含'invalid time'，识别出间隙（如美东 2:00–2:59）或重复（如欧陆 2:00–2:59）时段 - 对异常时段，自动生成带上下文的告警：
“2026-03-09T02:15 in America/New_York is ambiguous — use disambiguation=‘earlier’ or ‘later’” - 前端排班界面同步高亮此类条目，强制运营人员选择策略，留痕可追溯
