关键是要用 temporal.zoneddatetime 显性处理夏令时：必须带 iana 时区标识符（如 [asia/shanghai]）解析时间，立即转为 instant 统一基准，主动报错拦截夏令时异常，存储和比对均用 instant，前端展示才还原时区。
用 Temporal.ZonedDateTime 处理异步获取的全球考勤数据时，关键不是“避开”夏令时，而是让夏令时规则显性、可验证、不可绕过。它不帮你自动猜时间，而是强制你面对真实世界的时间规则——比如“2024-03-10T02:30 在纽约根本不存在”。只要构造时带 IANA 时区标识符、不用 Date、不传模糊字符串，就能堵住绝大多数考勤时间错位问题。
必须用 IANA 时区标识符，不能只写 +08:00
考勤数据常含原始时间字符串，如 "2026-04-25T09:15"。若直接加偏移 "+08:00" 构造 ZonedDateTime，就退化为静态偏移，失去夏令时感知能力。正确做法是绑定地理时区：
-
Temporal.ZonedDateTime.from("2026-04-25T09:15[Asia/Shanghai]")→ 永远按中国标准时间（无夏令时）解析 -
Temporal.ZonedDateTime.from("2026-04-25T09:15[Europe/Paris]")→ 自动识别 2026 年 3 月最后一个周日已切至 +01:00（夏令时） -
Temporal.ZonedDateTime.from("2026-04-25T09:15[America/New_York]")→ 正确使用 -04:00（夏令时中），而非错误的 -05:00
异步请求返回后立即归一化为 Instant
考勤数据来自多个地区 API，响应时间不同、格式不一。拿到每条记录后，第一时间转成 Temporal.Instant（UTC 瞬间），消除所有时区歧义：
- 对每条原始时间字符串，用
ZonedDateTime.from()解析（必须含[...]） - 立刻调用
.toInstant()得到统一基准点，例如2026-04-25T01:15Z - 后续排序、去重、计算间隔、存入数据库，全部基于
Instant，不再碰本地时区
主动拦截夏令时边界异常，而不是静默容错
考勤系统最怕“用户打卡成功但时间被 Date 自动挪走一小时”。ZonedDateTime 的价值恰恰在于报错：
- 遇到夏令时跳变时刻（如
"2026-03-09T02:15[America/New_York]"）→ 直接抛RangeError，提示“该时间在纽约不存在” - 遇到夏令时重叠时刻（如
"2026-11-02T01:30[America/New_York]"）→ 默认拒绝，除非显式指定disambiguation: "earlier"或"later" - 前端收到这类错误，可引导用户选择意图（“您是指夏令时前还是后的 1:30？”），避免后台凭空猜测
服务端存储与比对一律用 Instant，前端展示才还原时区
异步拉取的考勤数据入库前，不做任何“转成本地时间”的操作：
- 数据库字段存
TEXT或BIGINT（纳秒级Instant数值），不存字符串或 DATETIME - 查询某员工本周打卡，条件用
instant >= startInstant AND instant ，跨时区也精准 - 返回给前端时，附带原始 IANA 时区（如
"America/Los_Angeles"），由前端用ZonedDateTime.from(...).toLocaleString()展示本地格式
