先确认谁的当地时间是来源
“明天上午九点”对跨国协作来说不是完整的预约信息。先问清这是谁所在城市的九点，以及该城市日历上的哪一天，再填入时间转换器。来源用于解释输入，目标用于显示同一个时刻；输入日期不一定属于你的设备所在地，也不能自动当成目标城市的日期。
选择实际城市对应的 IANA 时区，而不是拿今天的时差加减到未来预约上。国家快捷入口只代表名称中说明的地区，多时区国家应选实际城市。附近城市也不一定可互换：国界、夏令时政策和历史规则都可能不同。目录没有匹配项时，不要仅凭距离挑一个看起来相近的城市。
用北京与洛杉矶检查跨日
来源选择北京，输入 2026-10-13 09:26，目标选择洛杉矶：
| 核对项目 | 应显示的结果 |
|---|---|
| 来源时间 | 北京 · 2026-10-13 09:26 · UTC+08:00 |
| 同一时刻的 UTC | 2026-10-13 01:26 |
| 目标时间 | 洛杉矶 · 2026-10-12 18:26 · UTC−07:00 |
| 日期关系 | 前一天 |
不能只告诉对方“18:26”，因为洛杉矶仍处在 10 月 12 日。若来源改成 2026-01-13 09:26，结果会是洛杉矶 1 月 12 日 17:26、UTC−08:00。这一小时差别来自所选日期的季节性规则，不是输入格式或界面语言造成的。
重要约定最好同时写出来源和目标读数，例如“北京时间 10 月 13 日 09:26／洛杉矶时间 10 月 12 日 18:26”。这样双方能发现日期或城市选错，也不用凭记忆推算时差。
日期错误与夏令时歧义是两类问题
工具接受 YYYY-MM-DD HH:mm，可附加秒数，支持 1970–2100 年的输入。不存在的日历日期应当修正，不应悄悄滚动到另一个月份。夏令时造成的缺口则需要回到原预约确认：纽约 2024-03-10 02:30 从未出现，不能把它当作有效当地时间继续换算。
纽约 2024-11-03 01:30 出现过两次，较早一次为 UTC−04:00，较晚一次为 UTC−05:00，两者相差一个真实小时。应询问组织者要哪一次，再选择对应选项；仅重复写“01:30”不能解决歧义。时区与夏令时指南解释了偏移与地区规则的区别。
编辑之后重新核对，不复制旧结果
更改来源城市或来源输入后，旧结果会清空。重新点击转换，再检查目标日期与“前一天／同一天／后一天”。添加其他目标城市只是显示已解析的同一个时刻；成功转换后交换城市，也会保留这个时刻，而不是简单交换两段文字。
12／24 小时制只改变读法。使用 12 小时制时不能漏掉上午／下午：12 AM 是午夜，12 PM 是中午。复制结果包含城市、完整日期、IANA 名称和偏移；自动复制不可靠时，可以使用工具提供的手动文本。
多人会议还要检查结束时间
一个城市的换算结果不能说明 90 分钟会议是否落在所有人的工作时段内。使用会议排期比较完整区间，并参考跨时区会议安排指南。未来政策可能变化，浏览器时区数据也可能滞后；重要活动临近执行时应重新确认。
技术参考：MDN 关于当地时间歧义的说明。