预约表只保存本地钟表时间，在夏令时切换时可能歧义。服务商需要明确时刻、命名时区，以及跳过或重复时间的处理，不能只在表单旁写时区缩写。
官方依据与范围
时区偏移切换时，本地钟表时间可能对应零个或多个实际时刻。 官方参考 · 2026年10月17日核对.
已填写的合成验收例子
合成教学例子，不是真实客户案例或真实平台测评。窄屏可横向滚动查看完整表格。
| 输入 | 核对口径 | 预期 |
|---|---|---|
| 墨尔本2026-04-05 02:30 | 4月4日15:30Z与16:30Z | 两个候选，必须明确选择 |
| 墨尔本2026-10-04 02:30 | 当地跳过这个钟表时间 | 拒绝或采用披露过的政策 |
| 确认2026-04-04T15:30Z | Australia/Melbourne | 第一次出现的02:30 |
可执行的交付检查
- 同时记录IANA时区和选定时刻，不把本地显示格式当标识。
- 按供应商实际时区数据库及支持浏览器测试重复与跳过时间。
- 确认信息、提醒与日历导出均对照同一个选定时刻。
怎样解释输出
附带Intl检查将两个明确时刻显示为重复的02:30，但不解析任意本地输入，也不实现完整时区求解器。业务方应先选择并披露歧义确认方式，再收费或承诺预约。
明确的适用边界
时区规则及平台支持可能变化，须核对当前tzdata；不创建真实预约，也不保证Temporal可用。本题不同于报表日期汇总及纯日期截止日。
复核有限教学模型
保存两份文件到同一目录，用Node22或更新版本运行下面命令。JSON包含输入与预期；脚本仅处理合成数据，无网络、密钥、付款或付费API调用。通过不等于真实系统已经通过验收。
node check.mjs booking-local-time-ambiguity-register.json