日期时间格式化与时区可移植性
区分时间点、日历日期、时区和语言显示，让网页日期在地区与夏令时变化下保持正确。
可靠的网页日期显示始于明确的数据模型。事件若是时间线上的一个点，就保存时间点；若只表示某个业务日，就保存日历日期；调用 Intl.DateTimeFormat 前，再决定明确的时区政策。区域设置负责语言和顺序，不会替应用决定预约使用哪个时区。分开这些选择，可以避免日期前后偏移、夏令时意外以及跨浏览器显示含义变化。
ECMA-402 国际化 API 定义依赖语言的格式化服务。MDN 记录面向浏览器的 Intl.DateTimeFormat 接口及其选项。W3C 时区说明解释日期与时区为何是不同信息。这些公开资料支持可移植的显示层，却不承诺所有运行时输出完全相同的标点或缩写。
先说明值的含义
时间点表示全球时间线上的一个位置。例如 2026-01-01T01:30:00Z 在任何地区都是同一时刻；末尾的 Z 表示 UTC。事件流、审计记录、付款授权和消息送达时间通常需要这种值，因为查看者可能身处不同地区。
日历日期含义不同。生日、酒店入住日、学校假期和计费周期可能只表示业务指定的那一天，并不指向午夜的某个瞬间。把它转换成时间点，再套用查看者时区，可能会变成前一天或后一天。领域没有时间概念时，应把日期作为日期保存和格式化。
当地墙上时间又是第三种情况。“柏林办公室 09:00”需要时区以及夏令时转换规则，不等于“查看者当前时区 09:00”。排程产品应说明使用场地时区、参与者选择的时区还是固定报告时区。格式化器不能补足缺失的排程决定。
不要把含糊字符串交给 JavaScript 解析器并期待浏览器猜对。定义输入合同并保留结构化字段：时间点应带偏移量或 UTC 标记；日期字段不要悄悄追加午夜；当地预约应同时保存当地字段和赋予其含义的 IANA 时区。
明确选择时区政策
Intl.DateTimeFormat 可以用 timeZone 选项格式化时间点。timeZone: 'UTC' 适合稳定的报告视图，timeZone: 'America/New_York' 表示该地区的民用时间及运行时所带的规则。省略选项通常使用运行时默认时区，适合查看者时钟，却不适合承诺固定时区的报告。
应用应拥有时区来源。用户可以在设置中选择，会议可以携带场地时区，组织可以规定报告时区。浏览器偏好最多是默认提示，不是居住地、国籍或身份的证明。时区影响决定时，应让用户看见并可以修改它。
跨地区会议、法律期限和财务截止时间不应只显示“晚上 8:30”。应显示时区名称、偏移量或清楚的周边标签，并说明是参与者当地时间还是场地时间。时区标识符是数据。周期性民用事件应保存 IANA 标识符；只有固定偏移量的格式无法表达未来夏令时变化。
使用 ECMA-402，而不是硬编码标点
格式化器接收语言、选项和时区。应用决定要显示哪些有意义的字段，格式化器决定顺序、数字、标点和本地化名称。语言协商和时区选择相互独立：可以用西班牙语标签显示多伦多时区的会议，也可以用法语标签显示固定 UTC 报告。区域设置不会翻译应用说明或用户内容。
不要要求每个浏览器版本产生完全相同的字符串。区域数据和排版可能变化。应测试结构化输入、选项和用户能否理解结果；只有产品真正控制的固定标签才适合精确快照。需要语义布局时可使用 formatToParts()，但不要假设各语言返回的顺序相同。
机器数据与人类显示必须分开。数据库、接口、日志和签名需要稳定合同，本地化字符串不适合反向解析成时间戳。输入字段应显示接受的格式，不能靠拆分斜线或猜测缩写时区。
把夏令时和日历边界当作常规情况
夏令时会产生不存在的当地时间，也会让一个小时出现两次。排程应用必须为不存在的时间和重复时间定义解决规则，并在保存前说明。Intl.DateTimeFormat 能显示已经解析的时间点，却不会替应用决定排程规则。
测试应使用真实 IANA 时区，覆盖春季跳变、秋季重复和普通日期。检查转换前后、周期事件以及查看者时区不同的预约。闰日和月长也会暴露问题：给时间点增加 24 小时不一定等于在民用日历中移动到“明天”。先应用领域规则，再格式化。
建立可移植回退
检测所需格式化功能，功能不可用时保留可读基线。回退可以使用服务器值、较简单的 Intl 选项或带 UTC 标签的结构化日期，但不能悄悄把场地时间换成查看者时间，也不能删掉截止时间的时区上下文。
列出支持的语言并解析请求标签。地区变体缺失时可以退回语言级别，但时区政策不能因此改变。浏览器和操作系统更新可能带来新的时区规则；保存原始时间点与 IANA 标识符，必要时保存受监管记录所需的显示证据。服务器和浏览器还应共享结构化值和声明的显示时区，避免一个先显示 UTC、另一个立即切换本地时间。
让显示无障碍且可行动
日期只有在能支持实际决定时才有用。为到期日、出发时间、续期日或测量值提供角色标签，跨地区情形显示时区。使用语义标签、可读文字、可换行布局，并检查放大文字、屏幕阅读器和从右到左语言。短显示形式缺少年份时，应提供完整的无障碍名称。
用户更改语言或时区时，应保留表单值和事件身份，并说明变化只影响显示还是也会改变预约。错误信息要说明字段期待日历日期、带偏移的时间点，还是当地时间加时区，并用当前语言给出例子。不要只显示“日期无效”。
用真实任务测试可移植性
建立固定时间点、日期值、场地预约和周期事件样例。将时间点分别用 UTC 与指定地区显示；日期值不应套用查看者时区；周期事件要跨越夏令时边界。使用 2026-01-01T01:30:00Z 时，UTC 是 2026 年 1 月 1 日 01:30，America/New_York 是 2025 年 12 月 31 日 20:30。两者应指向同一时间点并标出时区，标点和空格可以不同。
调查显示问题时记录应用版本、浏览器版本、操作系统时区数据、语言、输入值和产品政策。这些信息足以复现面向用户的结果，不需要建立浏览器特征清单，也不应把语言或时区偏好当成隐藏身份信号。
日期时间可移植性是一份产品合同：结构化值确定含义，明确的时区政策确定上下文，ECMA-402 提供本地化显示。分层后，浏览器更新可以只改变标点而不改变事件，用户也能改变语言或查看时区而不破坏已保存数据。
字段可命名为时间点、日历日期、当地时间和时区，让代码评审能发现无意转换。
有截止时间的邮件或通知应同时写出日期、时间和时区，因为消息可能脱离原界面阅读。
旧字符串迁移需要领域确认，把无时间日期转换为 UTC 可能改变用户看到的日期。
运维日志可统一使用 UTC，仪表盘再提供独立的查看时区选择。
测试应覆盖月末、年末以及带有历史规则的 IANA 时区。
布局应为较长的月份名称预留空间，并允许时区标签换行。
时区选择器应显示用户认识的名称，而不是容易混淆的数字偏移。
导出数据应保留时区上下文和值的类型，离开产品后仍能理解。
切换语言可以改变显示形式，但不应换算货币或修改保存的时间点。
服务器应先发送结构化值，再由浏览器按声明的政策显示，避免水合期间出现两套规则。
周期日历需要说明月份变化后不存在的日期如何处理。
重复出现的当地时间必须在确认预约前通过时间点或偏移量区分。
支持诊断只保留复现结果所需的数据，不应扩展为浏览器特征档案。
无障碍测试应朗读完整日期和时区，即使视觉界面采用缩写。
回退显示应保留日期和上下文，并使用受支持的语言解释原因。 时区缩写可能随版本变化，IANA 标识符和时间点才是稳定参照。
来源
语言协商可参阅浏览器语言本地化指南，通用格式化可参阅Intl 区域数据指南。这些主题不能替代应用对时间点、日历日期和当地预约的明确判断。