使用方法
- 「日期时间」默认填
2026-03-08T14:30，也就是北京 2026 年 3 月 8 日的下午两点半；「源时区」默认Asia/Shanghai、「目标时区」默认America/New_York。 - 点「开始换算」。结果区同时给出三个时刻：源时区本地 2026-03-08 14:30:00（偏移
UTC+08:00）、UTC 时刻 2026-03-08 06:30:00、纽约本地 2026-03-08 01:30:00（偏移UTC-05:00）。 - 「两城市时差」显示纽约比北京晚 13 小时，这是纽约仍在标准时 EST 时的数字。
- 把日期时间改成
2026-03-08T15:30再换算：纽约变成 03:30:00、偏移变成UTC-04:00，时差缩到 12 小时。差别的原因就在这一小时内纽约把时钟从 02:00 直接拨到了 03:00。 - 想验证秋季的重复小时，把日期时间依次改成
2026-11-01T13:30与2026-11-01T14:30，两次结果里的纽约墙钟都是 01:30:00，一次是 EDT、一次是 EST。 - 「互换源与目标」把两地对调后再算一次，用于反向核对；「载入默认示例」随时回到上面那组默认值；「复制结果」按纯文本复制整段换算说明。
这个时区转换器能解决什么问题
一是约会议时间不再靠心算。跟纽约的同事约下周一下午，只要把北京的墙钟时间填进去，立刻能得到对方当地的时刻与偏移，不必记住「冬令时差 13 小时、夏令时差 12 小时」这类会变的数字。
二是把日志里的 UTC 与本地时间对上。服务端日志普遍打 UTC，看的时候先把 UTC 列填进「日期时间」并把源时区选 UTC，目标时区选 Asia/Shanghai，就能得到北京时间。
三是避开夏令时切换那一小时的坑。纽约在每年 3 月第二个周日有一个不存在的本地小时，在 11 月第一个周日有一个出现两次的本地小时。把发布窗口、定时任务或航班时刻排在这两个窗口里，很容易出现「计划 02:30 执行、结果系统里找不到这个时刻」的问题，本页会把这两类情况直接标注出来。
四是确认中国全境的统一时刻。中国内地自 1991 年起不再实行夏令时，Asia/Shanghai、Asia/Chongqing、Asia/Harbin 全年都返回 UTC+08:00，只有以新疆作息为主的 Asia/Urumqi 返回 UTC+06:00。做全国排期时，用北京一个时区即可对齐。
本页不做这些事：不换算 Unix 时间戳与毫秒秒值、不处理 1970 年以前的历史时区、不算农历与节气、不判断某个地区某年是否调整过规则——这些都属于另外的工具。
换算原理：IANA 时区库、UTC 偏移与 Intl.DateTimeFormat
① 具体调用的接口。这个时区转换器取值只用一行：new Intl.DateTimeFormat('en-US', { timeZone: 'Asia/Shanghai', hour12: false, year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit' }).formatToParts(date)。formatToParts 返回的是一组带类型的片段，把它拼成 2026-03-08 14:30:00 这样的墙钟字符串，再用 Date.UTC() 把这个墙钟当成 UTC 算出毫秒数，两者相减就得到该时区在那一刻的偏移毫秒，除以 60000 得到偏移分钟数。
② 为什么用 IANA 标识而不是固定的偏移数字。固定偏移只能表达「永远差几小时」，而现实中同一座城市一年里会换两次偏移：纽约标准时 EST 是 UTC−5（−300 分钟 = −18000 秒），夏令时 EDT 是 UTC−4（−240 分钟 = −14400 秒）。用 America/New_York 这个标识，浏览器就会按内置的 tz database 自动判断某一瞬间到底该用哪个偏移；写成死的 UTC-5，一到夏令时就会整体差 1 小时。
③ 遵循的标准。时区标识来自 IANA tz database（也叫 zoneinfo / tzdata），采用「大洲/城市」的命名法，例如 Asia/Shanghai、America/New_York；Intl.DateTimeFormat 与其中的 timeZone 选项由 ECMAScript 国际化 API 规范定义，格式化数据来自 CLDR。浏览器与 Node 都自带这份数据，所以本页不下载任何时区表。
④ 输入到输出的转换路径。输入是一个「墙钟时间 + 源时区」的组合。第一步先用这个墙钟去猜一个 UTC 瞬间：guess = wallMs − offMin(tz, wallMs) × 60000；第二步用 guess 重新查一次该时区的偏移，如果和第一次不同（说明猜的时候正好落在夏令时切换附近），就用新偏移再算一次 utc = wallMs − offMin(tz, guess) × 60000。拿到 UTC 毫秒后，再对目标时区做一次 formatToParts，就得到目标城市的墙钟与偏移。
⑤ 边界与具体数字。所有偏移都以分钟为最小单位：中国 UTC+8 就是 480 分钟 = 28800 秒；纽约两种状态分别是 −300 与 −240 分钟；北京与纽约冬季相差 13 小时 = 780 分钟 = 46800000 毫秒，夏季相差 12 小时 = 720 分钟 = 43200000 毫秒。偏移并不都是整小时：新德里 Asia/Kolkata 是 +05:30，加德满都 Asia/Kathmandu 是 +05:45，澳大利亚 Australia/Eucla 是 +08:45，这些都是 15 分钟或 30 分钟的零头。年份允许 1900～2100。
⑥ 常见误用。把「夏令时」当成一个时区来选（它是某个时区在某段时间的规则，不是可选项）；以为南北半球同时进入夏令时（澳大利亚的夏令时正好在美国的非夏令时期间）；以为所有国家都有夏令时（中国内地、日本、印度都没有）；把 Asia/Shanghai 与 Asia/Urumqi 混用（前者 +08:00，后者 +06:00）。
完整示例：纽约 2026 年的两次夏令时切换
美国现行规则是「3 月第二个周日开始、11 月第一个周日结束」。2026 年对应的两个瞬间如下，全部由 tz database 实测得到：
- 春季（跳过小时）：UTC 2026-03-08 07:00:00 起，纽约偏移由
UTC−5变为UTC−4，本地时钟从02:00 EST直接跳到03:00 EDT。纽约本地 02:00:00～02:59:59 这 60 分钟根本不存在。证据：UTC 06:30 对应纽约 01:30（EST），UTC 07:30 对应纽约 03:30（EDT），中间那一小时没有对应值。 - 秋季（重叠小时）：UTC 2026-11-01 06:00:00 起，纽约偏移由
UTC−4变为UTC−5，本地时钟从02:00 EDT退回01:00 EST。纽约本地 01:00:00～01:59:59 这 60 分钟出现了两次。证据：UTC 05:30 对应纽约 01:30（EDT），UTC 06:30 也对应纽约 01:30（EST），同一个墙钟时间对应两个不同的瞬间。
把这两个结论代回页面默认值：北京 2026-03-08 14:30 对应 UTC 06:30，纽约是 01:30 EST，还没跨过切换点；把北京改成 15:30，UTC 变成 07:30，纽约就是 03:30 EDT。秋季同理：北京 2026-11-01 13:30 与 14:30 分别对应 UTC 05:30 与 06:30，纽约墙钟都是 01:30，前一个是 EDT、后一个是 EST。
顺带一个容易忽略的数字：春季切换日这一天，纽约本地只有 23 小时；秋季切换日有 25 小时。2026 年纽约处于 EDT 的天数是 238 天，其余 127 天为标准时。
常见城市时区对照与夏令时切换表
下表以页面默认瞬间（北京 2026-03-08 14:30，即 UTC 06:30）为基准，逐城列出当地墙钟与当时的偏移。注意纽约与洛杉矶此刻仍是标准时，悉尼、奥克兰则是夏令时：
| 城市 | IANA 时区标识 | 当地日期时间 | UTC 偏移 |
|---|---|---|---|
| 北京 | Asia/Shanghai | 2026-03-08 14:30:00 | UTC+08:00 |
| 纽约 | America/New_York | 2026-03-08 01:30:00 | UTC-05:00 |
| 洛杉矶 | America/Los_Angeles | 2026-03-07 22:30:00 | UTC-08:00 |
| 伦敦 | Europe/London | 2026-03-08 06:30:00 | UTC+00:00 |
| 巴黎 | Europe/Paris | 2026-03-08 07:30:00 | UTC+01:00 |
| 莫斯科 | Europe/Moscow | 2026-03-08 09:30:00 | UTC+03:00 |
| 迪拜 | Asia/Dubai | 2026-03-08 10:30:00 | UTC+04:00 |
| 新德里 | Asia/Kolkata | 2026-03-08 12:00:00 | UTC+05:30 |
| 东京 | Asia/Tokyo | 2026-03-08 15:30:00 | UTC+09:00 |
| 首尔 | Asia/Seoul | 2026-03-08 15:30:00 | UTC+09:00 |
| 悉尼 | Australia/Sydney | 2026-03-08 17:30:00 | UTC+11:00 |
| 奥克兰 | Pacific/Auckland | 2026-03-08 19:30:00 | UTC+13:00 |
| 圣保罗 | America/Sao_Paulo | 2026-03-08 03:30:00 | UTC-03:00 |
| 开罗 | Africa/Cairo | 2026-03-08 08:30:00 | UTC+02:00 |
| 檀香山 | Pacific/Honolulu | 2026-03-07 20:30:00 | UTC-10:00 |
第二张表是 America/New_York 2026 年的两次切换，用来对照上面讲到的跳过小时与重叠小时：
| 切换 | 切换瞬间（UTC） | 偏移变化 | 本地时钟 | 本地受影响的小时 |
|---|---|---|---|---|
| 春季 | 2026-03-08 07:00:00 | UTC-05:00 → UTC-04:00 | 02:00 EST → 03:00 EDT | 02:00～02:59 不存在（跳过 60 分钟） |
| 秋季 | 2026-11-01 06:00:00 | UTC-04:00 → UTC-05:00 | 02:00 EDT → 01:00 EST | 01:00～01:59 出现两次（重复 60 分钟） |
输入范围、边界与精度说明
下面这些范围是这个时区转换器刻意设定的边界，也是换算结果可能出现偏差的地方：
- 年份允许 1900～2100。再往前的年份，很多地区的偏移来自历史资料而非现行规则，浏览器内置的 tzdata 版本不同可能给出不一样的答案；再往后的年份则依赖对未来立法调整的假设，没有实际意义。
- 精度到秒，不处理闰秒。输入粒度是分钟（
step="60"），输出到秒。UTC 与 Unix 时间都不含闰秒，所以本页也不会出现「某分钟有 61 秒」这种结果。 - 偏移并不都是整小时。新德里 +05:30、加德满都 +05:45、澳大利亚 Eucla +08:45 都是真实存在的零头偏移，换算后分钟数不会归零，这不是计算错误。
- 跳过小时里的输入没有唯一答案。如果源时区恰好选在 2026-03-08 的纽约、时间又填
02:30，这个本地时间在纽约并不存在。工具仍会给出一个换算结果，同时在结果里明确标注「源时区处于夏令时跳过的小时」，提醒你这个输入本身是可疑的。 - 重叠小时里的输入有两个答案。同理，纽约 2026-11-01 的
01:30对应两个不同瞬间。工具按先出现的那一个（EDT）计算，并标注「重叠的小时」。 - 时差不是常数。北京与纽约冬季差 13 小时、夏季差 12 小时；中国内地与伦敦冬季差 8 小时、夏季差 7 小时。任何写死的时差数字一年里至少会错一段时间。
- 结果依赖浏览器的 tzdata 版本。如果某个国家刚改了夏令时规则，而你的浏览器还是旧版数据，结果就会落后一次更新。这类差异通常只出现在刚发布变更的年份。
常见问题
直接用固定偏移数字加减不是更简单吗？
只有在双方全年都不实行夏令时的情况下才安全。纽约、伦敦、悉尼这些城市一年换两次偏移，写死的数字必然有一段时间是错的。IANA tz database 里存的正是「哪个地区、从哪个瞬间起、用哪个偏移」的规则表，Intl.DateTimeFormat 的 timeZone 选项会按这张表自动取值，所以本页让你选城市标识而不是填偏移数字。
夏令时为什么会造成「跳过小时」和「重叠小时」？
因为切换是把本地时钟整体拨动一小时。春季拨快，02:00 直接变成 03:00，于是 02:00～02:59 这一小时在本地日历上从未发生；秋季拨慢，02:00 退回 01:00，于是 01:00～01:59 走两遍。前者会让「每天 02:30 执行」的任务在切换日被跳过，后者会让同一时刻的日志出现两条相差一小时但墙钟相同的记录。
为什么北京和纽约有时差 13 小时、有时 12 小时？
北京全年固定 UTC+8，纽约在标准时是 UTC−5、夏令时是 UTC−4，两者相差 13 小时或 12 小时。2026 年纽约处于夏令时的 238 天里时差是 12 小时，其余 127 天是 13 小时。所以跨时区排期要用工具算，不能凭印象。
中国为什么不实行夏令时？全境真的是一个时区吗？
中国内地自 1991 年起不再实行夏令时，全年固定 UTC+8。Asia/Shanghai、Asia/Chongqing、Asia/Harbin 三个标识返回的偏移完全一样，都是 UTC+08:00。唯一例外是 Asia/Urumqi，它返回 UTC+06:00，主要用于新疆本地的作息换算，法定时间仍以北京时间为准。中国东西横跨约 62 个经度，按每 15° 一个时区算理论上有 4 个时区，但行政上统一使用北京时间。
为什么工具算出来的时间和手机显示的不一样？
先确认三件事：输入的是不是源时区的本地时间（这个时区转换器不会假设你输入的是北京时间）；源时区有没有选对；手机是否处于「自动设置时区」。最常见的偏差来自第二条——把北京的时间填进去却把源时区留在 America/New_York，结果会整体差十几个小时。另外，若设备上的 tzdata 版本较旧，遇到刚调整过规则的国家也可能出现 1 小时偏差。
输入一个不存在的本地时间会怎样？
工具会照常给出一个换算结果，但会在结果里标注「源时区处于夏令时跳过的小时」。例如源时区选纽约、时间填 2026-03-08T02:30，这个墙钟在纽约并不存在，通常会被系统按切换后的偏移处理，等价于 03:30 EDT。遇到这类提示，正确做法是核对这个时间到底该写成 01:30 还是 03:30。
时区标识能不能用国家名？
不能。IANA tz database 用的是「大洲/城市」命名，且历史上为了兼容保留了一些并不对应城市的名字（例如 Asia/Calcutta 是 Asia/Kolkata 的旧写法）。只写 China 或 Beijing 都不被识别。写代码时如果拿不准某个标识是否有效，可以在浏览器控制台里试着构造一次 Intl.DateTimeFormat，无效标识会抛 RangeError。
填进去的时间会被上传吗？
不会。偏移查表、墙钟反推、格式化全部走浏览器自带的 Intl 接口，在当前页面完成，没有任何网络请求，也不写浏览器存储。想自己确认，打开开发者工具的 Network 面板连点几次「开始换算」，可以看到没有新请求发出。