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 获取用户浏览器时区，作为默认值提交，但允许用户手动切换（如常驻东京但出差纽约）