前端日历与时区：别用固定小时差换算城市时间

“某个时间”可能表示不同的东西：一个全球唯一的瞬间、一段本地墙上时间，或者一个没有时刻的日历日期。把它们都塞进一个 Date 再加减固定小时，通常会在设备时区、夏令时和跨日边界上出错。

先说明字段代表什么

如果服务端只保存“2026-10-15 09:00”却不说明它属于哪个时区，这个值无法唯一解释。API schema、数据库列和产品文案都应对齐同一种语义。

Date 解析不是任意字符串转换器

ECMAScript 标准日期时间格式最可移植；很多其他格式属于实现定义行为。特别要注意，标准格式的日期-only 字符串按 UTC 解释，而包含时间但没有时区的标准字符串按运行设备本地时区解释。像 YYYY-MM-DD HH:mm:ss 这样的空格分隔字符串不应依赖浏览器恰好能解析。

// 一个明确的时间瞬间：UTC 标记清晰。
const instant = new Date('2026-10-15T08:30:00Z');

// 日期-only 是“这一天”，不要把它用于表达本地预约时刻。
const birthday = '2026-10-15';

// 避免依赖实现差异：不要把任意本地日期字符串直接交给 Date。
const fragile = new Date('2026-10-15 09:00:00');

Date 主要表示时间线上的瞬间，不携带业务所需的城市时区。显示时可以明确指定时区：

const formatter = new Intl.DateTimeFormat('zh-CN', {
  timeZone: 'America/New_York',
  dateStyle: 'medium',
  timeStyle: 'short',
});

formatter.format(instant);

这解决的是“把已知瞬间显示到目标时区”。它并不会自动把用户输入的纽约本地 9 点转换成 UTC。

固定偏移无法表达城市时区

纽约、伦敦等城市在一年中的 UTC 偏移可能变化；政府也可能调整时区规则。保存 UTC-5 或把时间戳固定加 12 小时，只是在某个日期可能正确，不是可靠的时区模型。DST 切换还会产生不存在的本地时间和重复的本地时间：春季可能跳过一小时，秋季某一小时会出现两次。

当用户输入的是“某城市当地的预约时间”，需要一个时区感知的解析过程，并为歧义时刻定好产品策略：提示用户选择第一次/第二次、自动选择并明确告知，或拒绝该时刻。Intl.DateTimeFormat 适合格式化；浏览器原生 Temporal 仍需按目标运行环境检查兼容性，不能假设所有设备都有。可在服务端或经评审的时区库中统一完成“本地日期时间 + IANA zone -> instant”的解析。

// 后端请求字段示意，不是一个可单独运行的时间解析实现。
const appointment = {
  localDateTime: '2026-11-01T01:30',
  timeZone: 'America/New_York',
  // 当这个本地时刻因 DST 回拨出现两次时，解析策略也必须明确。
  disambiguation: 'later',
};

时区标识要使用 IANA 名称，而不是从当前偏移反推。用户偏好可记为一个时区；服务器日志、事件审计和跨系统交换则保留清晰的 UTC 瞬间。

日历单元格按“日期”处理

日历网格里的 2026-10-15 通常是一个日期标签，不是浏览器当地时区的午夜瞬间。用 new Date('YYYY-MM-DD') 再按本地时区格式化，可能显示成前一天。应在日期域里比较年月日，或使用明确的日期型表示。

const markedDates = new Set([
  '2026-10-15',
  '2026-10-22',
]);

function isMarked(calendarCell) {
  // calendarCell.dateKey 已由日历组件以 YYYY-MM-DD 生成。
  return markedDates.has(calendarCell.dateKey);
}

不要把 JSON.stringify(collection).includes(day) 当作日期查询：它会混淆相似字符串、依赖序列化格式且难以表达类型。Set 能明确成员关系，查找也不需要每次扫描整份 JSON。

如果日历展示跨时区会议，应先把每个事件瞬间格式化到用户选定的 zone，再决定属于哪一天；如果是全天假期，则保持日期值，不经过 UTC 转换。月历按天推进时用日历计算，不能把“下一天”简单等价为固定的 86_400_000 毫秒，因为本地时区切换日的墙上时间长度不总是 24 小时。

推荐的数据流

1. 确认来源语义。 接口字段明确是 UTC 瞬间、本地预约时间还是日期-only。
2. 在边界解析。 校验格式、时区标识和必填字段；不要把不可信字符串传给隐式解析。
3. 只在展示时转换。 把瞬间格式化到用户/组织选择的 IANA 时区，并显示必要的时区提示。
4. 保留原始语义。 全天日期不加 Z；远程预约不要丢掉原始 zone；日志事件保留 UTC instant。
5. 对歧义作决定。 本地时间落入 DST 缺口/重叠时，按产品规则处理并让用户能理解结果。

不要在数据库中只保存已格式化的显示字符串；它失去排序、区间查询、时区变化和本地化能力。也不要将客户端传来的时间偏移当成授权、结算或审计的可信依据。

测试矩阵

• 同一个 instant 分别显示在 UTC、东八区和有 DST 的城市，日期/时刻符合目标 zone。
• 午夜附近的 instant 跨时区显示时，日期变化符合预期。
• DST 开始时的不存在本地时间、结束时重复出现的本地时间符合已选策略。
• 所有时区输入都通过有效 IANA 标识校验；未知值应有清晰错误或组织默认值。
• 日期-only 的生日、假期在不同时区设备上仍是同一天。
• 浏览器时区变化、跨午夜定时任务和夏令时周边回归在目标运行时执行。
• 服务器和客户端使用不同 tzdata 版本时，未来预约的时区规则有明确的更新责任。

参考资料

• MDN：Date.parse() 与标准/非标准日期字符串
• MDN：Intl.DateTimeFormat
• MDN：Temporal.ZonedDateTime
• IANA：Time Zone Database