Temporal.PlainDateTime解决跨时区“今天”计算误差

跨时区业务中，“今天”的定义常常引发混淆，许多团队因依赖本地时区而出现计算错误。例如，直接使用 new Date().toDateString() 或 PlainDateTime.from(new Date()) 获取的只是服务器运行环境的本地时区日期，而非用户视角的“今天”。这种偏差在跨时区场景下极易导致订单统计遗漏或发货逻辑误判。

典型场景：订单系统部署在 UTC+0 服务器，用户位于东京（UTC+9）。凌晨1点下单，用户认为是“今天”，服务端却视为“昨天”。结果：“今日订单统计”漏单，“24小时内发货”逻辑错判。这不是偶然 bug，而是设计缺陷——未将时区作为第一性原理。

跨时区“今天”并非固定值，需显式锚定时区

核心问题在于：必须显式锚定时区，而非依赖本地环境。正确获取用户或业务视角的今日零点，需使用 Temporal.PlainDateTime 配合 .toZonedDateTimeISO('时区')。

用 Temporal.PlainDateTime 显式绑定时区语义

Temporal.PlainDateTime 本身不带时区，这正是其优势——仅表示“日历上的年月日时分秒”，不隐含偏移。它是构建时区敏感计算的正确起点，但需结合目标时区进行“锚定”。

• 用户所在城市为计算“今天”的基准？用 userTimeZone = 'Asia/Tokyo'，通过 PlainDateTime.with({ hour: 0, minute: 0 }).toZonedDateTimeISO(userTimeZone) 获取该时区今日零点。
• 公司财务日历以纽约时间为准？同理，PlainDateTime.with({ year: 2024, month: 6, day: 15 }).toZonedDateTimeISO('America/New_York') 才是“6月15日”的纽约时刻。
• 避免直接使用 PlainDateTime.from('2024-06-15T00:00') 解析字符串——它会默认按系统时区解释，再度陷入陷阱。

常见错误：将 PlainDateTime 误作“无时区的 Date”

许多开发者认为 PlainDateTime 是 Date 的安全替代，却写出如下代码：

const now = Temporal.Now.plainDateTimeISO();
const todayStart = now.with({ hour: 0, minute: 0, second: 0 }); //  错！这只是“当前系统时区的今天零点”的 PlainDateTime 表示

问题在于 todayStart 仍基于系统时区推导，一旦部署环境变更（如 Docker 容器未设 TZ），值就会漂移。真正需的是“用户视角的今天零点”，必须显式指定时区再转换：

const userZdt = now.toZonedDateTimeISO('Asia/Tokyo');
const todayStartInUserTZ = userZdt.withPlainTime(Temporal.PlainTime.from('00:00')).withPlainDate(userZdt.plainDate);
//  这才是东京用户认知里的“今天零点”

此处的 .toZonedDateTimeISO('xxx') 即为锚定动作。缺少它，所有 PlainDateTime 操作都只是模拟正确，而非真正正确。

性能与兼容性注意事项

Temporal 在 Chrome 108+、Firefox 113+、Safari 17.4+ 原生支持；Node.js 20.7+ 需开启 --harmony-temporal。旧环境需引入 @js-temporal/polyfill，但需注意两点：

• polyfill 的 toZonedDateTimeISO() 比原生慢约 3–5 倍。高频调用（如每笔订单计算“今日截止”）建议缓存时区对象：const tokyoZone = Temporal.TimeZone.from('Asia/Tokyo')。
• 避免在循环中重复调用 PlainDateTime.from(...) 解析同一字符串——先解析一次，再复用。
• PlainDateTime 不支持毫秒精度。若业务依赖毫秒级“今天”边界（如风控拦截），需使用 ZonedDateTime 配合 epochMilliseconds 计算。

归根结底，跨时区的“今天”并非靠猜测或格式化能解决，其本质是时区锚定动作。将时区绑定到具体的日历时刻，才算真正落地。