时区转换器
免费浏览器端时区转换工具。IANA 数据库、夏令时自动处理、多时区并排对比、可分享链接。零上传。
- 在浏览器中处理
- 数据不离开你的设备
- 免费 · 无需注册
用微信扫描以下二维码即可分享
示例、说明与常见问题 带实际输出的示例、与同类工具的差别，以及常见问题。
示例：北京时间上午 10 点在纽约是几点
美国从 3 月第二个星期日开始夏令时（2026 年是 3 月 8 日），中国现在不实行夏令时，所以两地时差在这一天前后从 13 小时变成 12 小时。源时区选 Asia/Shanghai，目标加 America/New_York，两个日期的结果如下：
| 基准时间（北京） | 纽约 | 该行徽章 |
|---|---|---|
| 2026-03-05 10:00 | 2026-03-04 21:00:00, UTC-05:00 (EST) | 4 天后切换夏令时 |
| 2026-03-10 10:00 | 2026-03-09 22:00:00, UTC-04:00 (EDT) | 1 天前已切换夏令时 |
固定在北京时间上午 10 点开的跨国会议，3 月 8 日之前在纽约是前一天晚上 9 点，之后变成晚上 10 点。纽约与北京之间没有固定时差，工具按每个日期当天的规则计算；美国的切换规则见 IANA 时区数据库 northamerica 文件中的 Rule US。
中国 1986–1991 年的夏令时
IANA 时区数据库的 asia 文件记录了中国在 1986 年至 1991 年实行过夏令时（规则名 PRC），夏季比标准时间快一小时，注释里列出了当年国务院公报的通知。同一文件还记录了 1919 年和 1940–1949 年的夏令时（规则名 Shang），规则与这一段不同。工具按历史日期取当时的规则，所以 1990 年夏天北京时间的偏移是 UTC+09:00：
- 源时区和目标都是 Asia/Shanghai：
1990-07-01 10:00:00, UTC+09:00 - 目标为 UTC：
1990-07-01 01:00:00, UTC+00:00
核对旧日志或档案时会碰到这种情况：把 1990 年夏天的北京时间一律减 8 小时换成 UTC，结果会差 1 小时。同年 4 月 15 日凌晨 2 点时钟拨到 3 点，当天 2:00–2:59 在当地并不存在。输入 1990-04-15 02:30，工具按跳过之前的偏移读取，得到 3:30：
1990-04-15 03:30:00, UTC+09:00
不存在与重复出现的时刻
夏令时开始时拨快的那一小时不存在，结束时拨回的那一小时出现两次。工具采用 RFC 5545（iCalendar）第 3.3.5 节的读法：不存在的时间按跳过之前的 UTC 偏移解释，所以往后顺延一小时；出现两次的时间取第一次。例如纽约 2026-11-01 01:30 出现两次，工具取第一次（EDT），换成北京时间是：
2026-11-01 13:30:00, UTC+08:00
如果要的是第二次出现的 01:30（EST），把源时区换成 UTC，输入 2026-11-01 06:30。
输入城市名的规则
「添加时区」和「源时区」只认英文城市名、UTC 和 IANA 名称。beijing、shanghai 都会解析为 Asia/Shanghai，这是北京时间在 IANA 数据里的名称，数据里没有 Asia/Beijing。输入「北京」会提示「未知时区，请输入城市或 IANA 名称。」。不区分大小写。只输入一部分也可以，但至少 3 个字符，必须是城市名里某个单词的开头，而且只对应一个时区：york 会找到 America/New_York，san 对应 San_Juan、Santiago 等多个时区，会被拒绝。CST、ist、JST 这类时区缩写也一律拒绝（CST、IST 各自对应多个地区，原因见下一节），提示同上。
为什么必须用 IANA 标识
PST、CST、IST 这类时区缩写有歧义：仅 CST 一项就可以指北美中部标准时间、中国标准时间或古巴标准时间。IANA 时区数据库用「大洲/城市」的方式（例如 America/Chicago、Asia/Shanghai、America/Havana）标识每个区域，并附带每个时区历史上的全部偏移与夏令时规则。
工具的计算都基于 IANA 标识；行内显示的缩写只供阅读，不参与运算。
夏令时与 7 天提示窗
工具找出目标时区在基准时间前后 7 天内的 UTC 偏移变化，按该时区的日历日计算基准日期与切换日期相差几天，在该行显示「n 天后切换夏令时」或「n 天前已切换夏令时」；切换就在基准日期当天时，显示「今天切换夏令时」或「今天已切换夏令时」。提醒你：同一个会议时间，切换前后换算出来的钟点不同。上面的例子里，纽约 3 月 8 日切换，北京时间 3 月 10 日上午 10 点在纽约是 3 月 9 日，所以显示「1 天前」。
当年不实行夏令时的时区（例如 Asia/Tokyo、Asia/Shanghai、Australia/Brisbane）显示「无夏令时」。判断方法是比较基准年份 1 月 15 日和 7 月 15 日的偏移，所以基准时间设在 1990 年时，Asia/Shanghai 不显示「无夏令时」。1 月和 7 月偏移相同、但前后 7 天内偏移有变化的时区照样显示切换天数，例如 Africa/Casablanca 在 2026-02-15 因斋月从 UTC+01:00 改为 UTC+00:00。
分享链接里有什么
网址 # 之后带三个参数：t 是基准时间，s 是源时区，z 是逗号分隔的目标时区列表。每次修改后工具都会更新地址栏里的这些参数，并非只在点击「分享链接」时才写入。打开链接的人在自己的浏览器里读取这些参数、重建对照。
隐私与离线使用
换算在浏览器里用 Intl.DateTimeFormat 完成，工具不发送你输入的时间和时区。源时区和目标列表存在本浏览器的本地存储里，基准时间不存，但会和源时区、目标一起写在地址栏 # 之后，留在浏览器历史里。按 RFC 9110 第 7.1 节，请求的目标网址不含 # 之后的部分，所以分享链接里的值不会随页面请求发到服务器。页面打开后断网仍可继续换算；本站没有离线缓存，关闭后需联网才能重新打开。
限制
- 缩写取自浏览器的英语（加拿大）区域数据，只有北美时区有（EST、PDT、AKST 等）；中国标准时间不显示 CST，日本的 JST 也不显示。UTC 偏移始终显示。
- 搜索候选来自
Intl.supportedValuesOf(‘timeZone’)，每个时区只列一个名字，不同浏览器引擎列出的名字不同：Chrome 列出Asia/Calcutta、Europe/Kiev，而不是Asia/Kolkata、Europe/Kyiv，也没有UTC。这些名字手动输入都能用。 - 时区数据是浏览器自带的那一份。某国临时修改规则后，在浏览器更新之前，未来日期的结果可能不对。
- 基准时间带秒时会保留秒；没有工作时间网格或会议规划视图。
- 处理 Unix 时间戳请用 时间戳转换器。
FAQ
如何处理夏令时？
工具通过 Intl.DateTimeFormat 使用浏览器自带的 IANA 时区数据，按你输入的日期套用当时的规则，过去和未来的日期都一样。某个目标时区在基准时间前后 7 天内改变 UTC 偏移时，该行会显示切换提示。落在春季拨快、被跳过的那一小时里的时间，会顺延一小时读取。
为什么和其他时区工具的结果不一样？
每个浏览器自带一份 IANA 数据，随浏览器版本更新；刚宣布的规则变更不一定已经进入所有浏览器。别的工具可能用固定偏移代替时区，或者把 CST 这类缩写理解成另一个地区。巴西 2019 年取消夏令时这类历史变更，只要浏览器的数据里有，就会按新规则计算。
能把转换结果分享给其他时区的人吗？
可以。点击「分享链接」，网址 # 之后包含基准时间、源时区和目标时区，对方不论身在哪个时区，打开后看到的都是同一组对照。对方浏览器不认识的时区名会被略去。
输入的时间和时区会被发送或保存吗？
工具不会把它们发出去，换算由浏览器的 Intl.DateTimeFormat 完成。源时区和目标时区列表保存在本浏览器的本地存储（localStorage）里。基准时间不存进本地存储，但每次修改后，工具都会把基准时间、源时区和目标时区写进地址栏 # 之后，所以它们会留在浏览器历史里，刷新页面也会恢复。浏览器请求页面时不会把 # 之后的部分发给服务器；2026-10-08 本地实测，页面统计上报的页面地址也不含这一部分。页面统计只记录工具名和用了哪个按钮（现在、添加、复制摘要、分享链接）。
可以离线使用吗？
换算本身不需要网络：时区数据内置在浏览器里，页面打开后断网也能继续换算。本站没有离线缓存，页面关掉后要联网才能重新打开。
浏览器不支持 Intl.supportedValuesOf 怎么办？
搜索候选会退回内置的 58 个常用时区，例如 Asia/Tokyo、America/New_York。Chrome 99、Firefox 93、Safari 15.4 起支持 Intl.supportedValuesOf。其他合法的 IANA 名称照样可以手动输入，因为工具用 Intl.DateTimeFormat 校验名称。