一、它解决什么场景问题

远程办公普及后，“会议到底几点开"成为跨国团队的第一内耗源：发起人写"15:00”，没人知道是哪个时区的 15:00；即使写了"15:00 (UTC+8)"，伦敦同事仍要心算 07:00。本应用用会议排期工具承载 intl.DateTimeFormat 的时区能力，解决三类场景：

1. 对时间：同一会议，每个参会人看到自己的本地时刻；
2. 看时钟：常驻城市同屏对比当前时间（何时联系对方不打扰）；
3. 排会议：给跨时区同事定时间时，先看各城市此刻，再选共同窗口。

二、典型用户故事

故事 A：产品经理 Amy（北京，zh_CN）
Amy 要组织中英美三方产品周会。她在"时区换算器"里输入 15:00 UTC，看到北京 23:00、伦敦 16:00、纽约 11:00——意识到晚上 11 点对北京同事太晚，改选 09:00 UTC（北京 17:00、纽约 05:00），最终定在 14:00 UTC，所有人都在工作时间。

故事 B：工程师 Dan（纽约，en_US）
Dan 的团队用 UTC 存会议时间。他把 App 切成英文，看到会议列表里"产品周会 11:00 AM"（纽约本地）与 “07:00 UTC” 并列——一眼确认自己没记错时区，不用再打开第三个换算网站。

故事 C：外包设计师 Sato（东京，ja_JP）
Sato 每天上午要看设计走查会议是否改期。切到日语界面后，"9:00（日本時間）"的显示符合他的阅读习惯，日期风格也变成「2026年8月20日（木）」。

故事 D：跨境客服 Linda（zh_TW）
Linda 服务欧美客户，客服系统 SLA 承诺"4 小时内响应"。她把 App 切到繁体中文，世界时钟同时显示台北与纽约时间——看到纽约此刻是凌晨 2 点，她判断客户可能还没看到工单，把跟进时间定在纽约上午 9 点，既遵守 SLA 又不打扰客户。跨时区客服排班的每个决定，都依赖"一眼看清两地此刻"。

三、适用使用环境

环境类型	适配说明
远程办公工具	团队会议排期、跨时区协作
国际项目协作	外包/多地域团队对齐时间
差旅规划	出发前确认会议在各城市的时刻
客服/支持系统	SLA 时间跨时区换算
开发者自测	验证 timeZone 与 dateStyle 组合

四、目标用户画像

1. 跨国团队负责人：需要快速定一个大家都能参加的时间；
2. 分布式开发者：查看 CI 部署、发布窗口在各时区的时刻；
3. 海外商务/客服：确认对方工作时间再发起沟通；
4. 差旅人士：出发前把行程中的会议时刻换算成目的地时间。

五、关键设计决策

1. UTC 存储，本地展示

时间在数据层只有一个事实（UTC 时间戳），展示层投影到各时区。任何业务逻辑都不得拼"本地时间字符串"，否则夏令时一换就错：

// 数据层：只有 utcTime 一个事实
{ id: 'm1', topic: '产品周会 · Sprint 规划', hostTz: 'Asia/Shanghai',
  utcTime: Date.UTC(2026, 7, 19, 7, 0), durationMin: 60 }

// 展示层：按需投影
private meetingLocal(m: Meeting): string {
  return fmtInTz(this.currentLocale, m.hostTz, m.utcTime);
}
private meetingUtc(m: Meeting): string {
  return fmtInTz(this.currentLocale, 'UTC', m.utcTime);
}

2. 发起人时区优先

会议列表显示"发起人本地时刻"（谁定的会，以谁的时区为准），同时并列 UTC 对照——这是会议产品的常见约定，避免"我这边 3 点"的歧义。

3. 语言与日期风格联动

切换语言时，日期写法（full/long/medium/short）与 12/24 小时制都随 locale 变化——用户看到的是"自己的时间习惯"。

4. 夏令时自动处理

城市表存 IANA 时区名（Europe/London），不是 UTC+0 或 UTC+1。伦敦 3 月底切夏令时、10 月底切回来，intl 自动处理，代码零改动：

// 你只需要存 IANA 名
{ key: 'london', name: '伦敦', tz: 'Europe/London', flag: '🇬🇧' }
// 夏令时切换由 intl 内部处理，无需任何额外代码

六、场景工作流：一次完整的跨时区排期

以 Amy 组织三方周会为例，走一遍 App 内的完整操作流：

1. 打开 App，默认中文界面
2. 看世界时钟：北京 14:30、伦敦 07:30、纽约 02:30（凌晨）
   → 判断：现在联系纽约同事不合适
3. 看会议列表：本周产品周会，纽约 David 主持
   → "本地时刻: 2026年8月19日星期三 22:00"（纽约本地晚上 10 点）
4. 点开时区换算器：
   → 输入 UTC 15:00，切换城市看北京 23:00 / 伦敦 16:00 / 纽约 11:00
5. 切到英文界面复查，确认 "11:00 AM" 与团队邮件一致
6. 给参会人发邀请："周四 15:00 UTC"

每一步都体现一个 i18n 要点：世界时钟验证"此刻"、列表投影"各自本地时刻"、换算器预测"未来时刻"、语言切换复查"双语言一致"。

七、边界与降级

• 未知时区：timeZone 传非法值会抛异常，try/catch 降级 toString()；
• 夏令时切换日：IANA 时区自动处理，无额外代码；
• 秒级刷新性能：6 城市可接受，上百城市需优化（见技术篇）；
• 旧设备：dateStyle/timeStyle 需 API 8+，HarmonyOS 全版本满足。

七·五、一次语言切换的完整链路（场景复盘）

以"会议列表从中文切到英文"为例，拆解 currentLocale 的响应式传导：

用户点击「🇺🇸 EN」胶囊
   │ 1. onClick 赋值
   ▼
this.currentLocale = 'en_US'        // @StorageLink 全局状态
   │ 2. AppStorage 广播 + PersistentStorage 落盘
   ▼
T(key) 重新执行                     // 文案：标题/按钮/卡片标签全变英文
meetingUtc(m) 重新执行              // "UTC 时刻: Wed, Aug 19, 2026, 7:00 AM"
meetingLocal(m) 重新执行            // "Local: Wed, Aug 19, 2026, 3:00 PM"（北京）
clockTz(...) 重新执行               // 世界时钟变 12 小时制 + AM/PM
fmtStyle(...) 重新执行              // 日期风格表全换英文写法
   │ 3. ArkUI 增量渲染
   ▼
页面整体刷新，无闪烁、无空白

这个链路的价值：用户切换语言时，时间格式是"活的"——不仅文案变，连 12/24 小时制、AM/PM、日期顺序（月日年 vs 日月年）都跟着变。这靠的不是遍历控件，而是声明式 UI 的状态驱动：所有显示都从 currentLocale 派生，状态一变，框架自动重算所有依赖它的格式化结果。

八、竞品对比

方案	优点	缺点	本应用选择
手写偏移表（UTC+8 字典）	简单	夏令时必错、维护困难	拒绝
intl.DateTimeFormat timeZone	标准、自动夏令时	需传 IANA 名	✅
第三方时区库（moment-timezone）	功能全	引入依赖、体积大	无需
服务端统一换算	数据一致	客户端离线不可用	混合（本应用纯本地）

九、多时区场景的常见坑（真实踩过的）

1. 只写 15:00 不写时区：发起人默认"我的时区"，跨时区后歧义产生——约定一律带时区后缀或链接；
2. 用 UTC+8 字符串做换算：+8 只是"当前"偏移，东京/首尔/北京同为 +9/+9/+8，但夏令时政策不同，+9 无法表达东京的 DST（日本无夏令时，而韩国也稳定）——同偏移 ≠ 同时区；
3. 忘记会议跨日：纽约 03:00 对应北京前一天 15:00，只显示"3 点"不显示日期会误导——本应用 dateStyle: 'full' 带星期与日期；
4. 把 12/24 小时制写死：英文用户习惯 12 小时制、中文用户习惯 24 小时制，写死其一就是得罪另一半用户；
5. 只测自己的时区：伦敦测了 07:00 就以为成功，纽约/东京没跑过——至少测"东八区 + 西五区 + 本初子午线 + 日界线"四类。

十、与相邻应用的关系（场景视角）

• 应用 01 多语言：只切语言不切时区，时间是"设备本地"；
• 本应用 02：语言 + 时区双维，时间是"投影"；
• 应用 11 地区/时区：把时区从"城市表"升级为"可搜索的地区数据库"（国家代码 → 时区 → 货币），业务从会议扩展到航班；
• 应用 13 订单：订单的"下单时间"也必须存 UTC + 展示本地，否则财务对账错乱——02 是它的时间地基。

十一、扩展方向

• 会议链接生成：把"UTC 时刻 + 各参会人时区"生成日历邀请文本；
• 最佳时段推荐：根据所有参会人工作时段自动求交集；
• 夏令时日历：标注目标城市下次夏令时切换日期。

十二、生产级注意事项

1. 统一用毫秒时间戳：跨层传递（数据/网络/UI）一律用 number 毫秒，不要传字符串，避免格式歧义；
2. Date.UTC 而非字符串解析：new Date('2026-08-19 07:00') 的解析结果依设备时区而定，必须用 Date.UTC(2026, 7, 19, 7, 0) 显式指定；
3. 时区表可下发热更：IANA 时区名列表放服务端，新时区（如某些国家的政治时区变更）无需发版；
4. 测试夏令时边界：至少测 3 月/10 月切换日前后各一天，验证会议时间不偏移；
5. 会议结束时间：用 start + duration 计算而非存结束时间，避免夏令时切换导致时长漂移。

十三、结语

时区问题的本质是信息模型问题：存 UTC、显示本地、用 IANA 名。这个应用用会议排期这个真实场景，把 DateTimeFormat 的 timeZone 能力讲透。