Toolify

时区转换器 (跨多个时区比较时刻)

选源时区与日期/时间, 然后按需添加多个目标时区。每个目标显示对应当地时间与时区缩写。

添加时区:
America/New_York
Europe/London
Asia/Tokyo

工作原理

时区转换如何工作

每个时刻都是单点 — 东京周二早 9 点与旧金山周一下午 5 点是同一时刻。时区转换只是用每个区的本地钟面时间重新标注那个单一时刻。夏令时让事情复杂 — 美国 3 月到 11 月间, 东部时间是 UTC-4 (EDT); 其他时间 UTC-5 (EST)。浏览器的 Intl.DateTimeFormat 在你传 'America/New_York' 这样的 IANA 时区名时正确处理这一切。

我们用 IANA 名 (如 'Asia/Tokyo' 或 'Europe/London') 因为它们无歧义且历史上遵循各地的 DST 规则。'JST' 或 'GMT' 是可能冲突的缩写; IANA 名不会。

常见安排陷阱

DST 切换: 「下周二早 9 点 EST」在 3 月或 11 月有歧义因规则变化。总说「纽约时间」或发日历邀请 — Outlook、Google 日历、Slack 在双方都指定时区时正确处理转换。

半小时偏移: 印度 UTC+5:30、纽芬兰 UTC-3:30、澳洲部分 UTC+9:30 或 +10:30。如果你的会议数学按「整小时」, 这些地区会差 30 分钟。

跨日界线跳跃: 东京到旧金山是次日还是同日依方向。日历显示正确, 但人的假设可能错。

有用模式

国际站会: 选源时区 (常 UTC) 和团队主时区。设会议时间, 验证没人被叫凌晨 3 点参加。

产品发布: 选发布区, 加主要市场。验证营销邮件抵达合理本地小时。

出行规划: 选出发区, 加目的地区, 找本地到达时间无需手动数学。

常见问题

处理 DST 吗?

处理 — IANA 时区数据含每个地点的 DST 规则。浏览器 Intl API 处理过去、现在、(已知的) 未来切换。

EST 与 ET 区别?

EST 固定 UTC-5。ET (东部时间) 冬季是 EST, 夏季是 EDT — 跟踪 DST。我们用 IANA 名如 'America/New_York' 按日期自动选 EST 或 EDT。

可以在两个特定城市间换算吗?

可以。一个设源, 另一个加为目标。显示时间是源时刻用目标本地钟面表达。

为什么有些区有 :30 偏移?

历史决定。印度、伊朗、阿富汗、纽芬兰、澳洲部分都用相对 UTC 的 30 分或 45 分偏移。计算器正确处理。

支持过去日期?

支持, 含历史上可能不同的 DST 边界。IANA 数据覆盖多数地点 1970 年起的历史。

南极或夏威夷呢?

IANA 列表含。需要请从下拉添加 'Pacific/Honolulu' 或 'Antarctica/McMurdo'。

数据会上传吗?

不会。浏览器 Intl API 全本地处理。

可以保存我的时区列表?

暂不能。刷新重置列表。可能稍后加 local-storage 持久化。

相关工具

最后更新: