“纽约早上九点”还不足以确定一次会议
同一座城市在不同日期可能使用不同的 UTC 偏移。OmniKit 根据选定日期和命名时区计算结果，不把两地时差固定成一个全年不变的小时数。因此，安排跨国会议时要同时确认日期、时间和城市时区。
下表在 2026 年 9 月 5 日对照当前工具函数与 Node 的 Intl 时区数据验证。网页运行时使用浏览器提供的时区数据库；如果当地规则发生变化，应保持浏览器更新。
| 出发地日期与时间 | 来源 → 目标 | 换算结果 |
|---|---|---|
| 2026-01-15 09:00 | America/New_York → Asia/Shanghai | 2026-01-15 22:00 |
| 2026-07-15 09:00 | America/New_York → Asia/Shanghai | 2026-07-15 21:00 |
| 2026-09-05 00:30 | Asia/Shanghai → America/Los_Angeles | 2026-09-04 09:30 |
前两行同样是纽约早上九点，换成上海时间却相差一小时。第三行则回到了前一天。如果只复制结果的“几点”，就会丢失可能改变约定日期的重要信息。
有些本地时间实际不会发生
把来源设为 America/New_York，日期填 2026-03-08，时间填 02:30。当前工具会提示该本地时间不存在。春季夏令时切换会跳过一段钟面时间，不能把被跳过的 02:30 当作普通时刻处理。
如果这来自真实预约，应向发起人确认一个有效时间或带明确 UTC 偏移的时间戳。为了让工具接受输入而随意修改小时，会改变预约本身。
有些钟面时间一天会出现两次
秋季切换时，纽约的 2026-11-01 01:30 可能对应两个不同时刻。当前工具只会返回其中一次，没有提供“第一次 / 第二次”的选择器。
遇到重复时间，应获取原始时间戳或明确的 UTC 偏移，再按该时刻核对。当前本地时间表单不适合用来选择重复时段中的另一次。
分享换算结果时要保留什么
- 按发起人的日期输入，来源时区选择发起人所在城市。
- 选定接收方时区，完整读取结果的日期、时间和 UTC 偏移。
- 周期性会议应分别检查季节切换前后的日期。
- 在邀请中保留完整日期和城市时区；不存在或有歧义的时间，应先确认原始时刻再安排。
实现背景：MDN Intl.DateTimeFormat 文档。这些例子用于说明当前工具行为，不代表时区政策永远不会变化。