Temporal.ZonedDateTime 是全球化打卡校验最可靠的时间类型——它将“某地某刻”锚定于真实世界，通过显式绑定城市时区（如 "Asia/Tokyo"）构造带上下文的时间点，确保“今日”按当地日历定义，精准支持夏令时与日边界判断。
Temporal.ZonedDateTime 是处理全球化打卡校验最可靠的时间类型——它把“某地某刻”真正锚定在真实世界中，而不是靠偏移量硬算。关键不在于“转换快”，而在于“语义准”：打卡是否在「用户所在时区的今日 9:00 前」完成？这个“今日”必须按东京、纽约或上海各自的日历规则来定义，不能简单用 UTC 或固定 +8 小时推算。
用 ZonedDateTime 显式绑定打卡发生地
用户提交打卡时间时，只传一个本地时间（如 "2026-04-29T08:45"）和所在城市（如 "Asia/Tokyo"），后端立即构造 ZonedDateTime：
- 不要先转成 Instant 或 UTC 再处理——那会丢失“今天”的地域含义
-
要直接用
Temporal.ZonedDateTime.from({ year, month, day, hour, minute, timeZone: 'Asia/Tokyo' })构造带完整时区上下文的时间点 - 这样哪怕用户在夏令时切换日打卡（如欧洲 3 月最后一个周日），系统也能自动识别是“当地时间 02:30 还是 03:30”，不会误判为跨天
校验逻辑必须基于目标时区的“日边界”
判断是否“今日打卡”，本质是比对两个 ZonedDateTime 是否落在同一“本地日期”内：
- 取用户打卡时间
zdtCheck和该时区当日零点zdtTodayStart = zdtCheck.withPlainTime({ hour: 0, minute: 0, second: 0 }) - 再取次日零点：
zdtTomorrowStart = zdtTodayStart.plus({ days: 1 }) - 校验条件：
zdtTodayStart - 注意：全程不涉及 toInstant()、不转 UTC、不手动加减小时——所有计算都在同一 ZoneId 下进行
异步任务中保持时区上下文不丢失
打卡成功后触发的延时校验（如“30 分钟内未补卡则标记缺勤”），需确保定时器启动时刻与执行时刻都使用相同地理语义：
- 存入任务队列时，记录的是
zdtCheck.epochNanoseconds（瞬时点）+zdtCheck.timeZone.id（时区标识） - 任务执行时，重建 ZonedDateTime：
new Temporal.ZonedDateTime(epochNs, timeZoneId)，再按前述方式比对“当前是否已过宽限期” - 避免只存 LocalDateTime 或字符串——一旦服务部署在 UTC 服务器，重建时默认用系统时区，东京用户就可能被误判
与数据库和前端协同的关键约定
全链路时区一致性靠三端约定，不是单靠代码：
-
数据库：只存
Instant（即 epochNanoseconds），字段类型用 BIGINT 或 TIMESTAMPTZ；绝不存“2026-04-29 08:45”这类无时区字符串 -
后端接口：接收打卡请求时，强制要求客户端传
timeZone字段（IANA 标准名，如 "Asia/Shanghai"），拒绝 "GMT+8" 或 "CST" -
前端：调用
Intl.DateTimeFormat().resolvedOptions().timeZone获取用户浏览器时区，作为默认值提交，但允许用户手动切换（如常驻东京但出差纽约）
