输入日期和时间，说明它属于哪个时区，页面会在你列出的每个时区里显示同一个瞬间：当地时钟、当地日期、相对 UTC 的偏移、时区简称，以及当地是否实行夏令时。
时区转换器 - Danfio
https://danfio.com/tools/time-zone-converter/ - 从本页打印
UTC 时间
2026 年 9 月 16 日（星期三），12:00
本时区为 UTC，所以这就是 UTC 瞬间本身。
| 时区 | 当地时间 | 当地日期 | 偏移 | 名称 | 日期差 | 夏令时 |
|---|---|---|---|---|---|---|
| UTC | 12:00 | 2026-09-16 | UTC | UTC | 同一天 | 否 |
| America/New York | 08:00 | 2026-09-16 | UTC-04:00 | EDT | 同一天 | 是 |
| America/Los Angeles | 05:00 | 2026-09-16 | UTC-07:00 | PDT | 同一天 | 是 |
| Europe/London | 13:00 | 2026-09-16 | UTC+01:00 | GMT+1 | 同一天 | 是 |
| Europe/Berlin | 14:00 | 2026-09-16 | UTC+02:00 | GMT+2 | 同一天 | 是 |
| Asia/Kolkata | 17:30 | 2026-09-16 | UTC+05:30 | GMT+5:30 | 同一天 | 否 |
| Asia/Shanghai | 20:00 | 2026-09-16 | UTC+08:00 | GMT+8 | 同一天 | 否 |
| Asia/Tokyo | 21:00 | 2026-09-16 | UTC+09:00 | GMT+9 | 同一天 | 否 |
| Australia/Sydney | 22:00 | 2026-09-16 | UTC+10:00 | GMT+10 | 同一天 | 否 |
每一行都是同一瞬间用不同时钟读出的结果。日期差一列比看起来更重要：洛杉矶的 09:00 在东京已是第二天早晨，多数国际会议安排错误就出在这里。
| 变更 | 当地变更时间 | 变更前偏移 | 变更后偏移 | 时钟 |
|---|
这个时区不调整时钟，所以一年中每个日期的偏移都相同。空表就是答案，而不是没有找到答案。
它还会打印参考时区当年的时钟变更，这些是通过比较偏移找出来的，而不是查一张日期表。这很重要，因为规则是政治而不是天文：国家会改规则，而一个建立在硬编码 DST 日期表上的时区转换器，会在政府改动日期的那一刻出错。
偏移来自你浏览器里的 IANA 时区数据库——也就是你电脑显示时钟所用的同一份数据——所以没有任何内容被发送出去，答案遵循该数据库持有的规则。页面会说明这一点，因为这是本页唯一会动的部件。
偏移是规则而不是固定数字，本页也这样对待它们：它从你电脑使用的同一份 IANA 数据库读取转换瞬间的偏移，打印两侧的当地时钟和日期，并展示答案背后的当年时钟变更。
方法是把选定的瞬间在目标时区里格式化，读回墙上时钟的数字，再把这些数字当作 UTC 来比较——差值就是偏移；这样能保留四分之一小时的时区，而按小时取整会把它们抹掉。全部通过浏览器自带的国际化 API 在本地运行，所以你的日期不会被发送到任何地方。
这些都无法修正一个真正模糊的时间，因为时区在时钟变更时重复或跳过的那一小时，并不对应唯一瞬间。它也无法纠正时区数据库过期的浏览器；那种情况下，页面会同意你的电脑，而不是新闻。当答案必须精确时，用 UTC 约定时间。
人们很容易把时区想成相对 UTC 的几个小时，这在多数时候管用，直到不管用。Europe/London 在一月是 UTC，在七月是 UTC+1；America/New_York 从 −5 变成 −4；Australia/Sydney 从 +11 变成 +10，顺序相反，因为那里的夏天在十二月。偏移是规则在某个特定日期的说法，不是地点的属性。
这就是本页在转换的瞬间读取偏移，而不是为每个时区存一个数字的原因。Asia/Kolkata 或 America/Sao_Paulo 这样的时区名，承载着该地区自 1970 年以来对时钟做过的全部历史，数据库知道每一次变更。
有些偏移不是整小时。印度是 +5:30，尼泊尔 +5:45，澳大利亚部分地区 +9:30，纽芬兰 −3:30，查塔姆群岛 +12:45。页面用分钟而不是小时计算偏移，所以这些都不会被四舍五入掉。
本页代码里没有时区表。偏移通过内置国际化 API 从浏览器自己的 IANA 数据库副本读取；该 API 不能直接报告偏移，所以页面先把瞬间在目标时区里格式化，读回墙上时钟的数字，再把同样的数字当作 UTC 来解释。差值就是偏移。
后果值得直说：如果政府改了规则，而你浏览器的数据库还没更新，本页就会以和你电脑时钟相同的方式出错。数据库通常随浏览器或操作系统更新，国家也通常提前几个月宣布变更，但上周才改的规则可能还没进去。
同一份数据库也决定时区叫什么：GMT、BST、CET、IST、JST 等等，按平台的拼法。缩写并不唯一——IST 可以是印度、爱尔兰和以色列——所以页面同时提供名称和偏移，也因此在时区列表里使用 IANA 名称而不是缩写。
当时区在秋季退出夏令时时，当地时钟回拨一小时，所以 01:00 到 02:00 之间的那一小时会发生两次；这一小时里的墙上时间确实模糊，页面会按其迭代选择第一个，而不是声称确定。春季时钟向前跳，02:00 到 03:00 之间的那一小时根本不存在：这一小时里的时间在当地从未发生过。
这不是页面的缺陷，而是当地时间的属性。任何要在这些小时里安排事情的人，最好用 UTC 约定瞬间，让各方自行换算。页面打印它所展示的一切的 UTC 对应值，正是为了这个原因。
它不转换会议系列、不维护日历，也不处理“每月第二个星期二当地 10:00”——那需要能感知时区的日历，因为跨时区的重复会议会在只有一方改时钟时漂移一小时。页面展示漂移发生的原因；它不解决这个问题。
它也不知道国家内部的时区边界。数据库知道某个时区存在，但不知道你在哪个县：有些国家横跨多个时区，有些地区退出了夏令时而其余地区没有。你选的时区，就是你得到的时区。
示例使用页面自带的默认输入，只改设置；下面的结果与你在页面上看到的完全一致。
日期和时间: Sep 16, 2026 · 12:00 · 上面的时间属于: UTC · 要比较的时区: 8 items
UTC 时间
2026 年 9 月 16 日（星期三），12:00
本时区为 UTC，所以这就是 UTC 瞬间本身。
UTC: 2026-09-16 12:00 · 相对 UTC 的偏移: UTC · 时区名称: UTC · 夏令时: 未实行
纽约 08:00、洛杉矶 05:00 是同一天，悉尼 22:00 也是同一天，因为澳大利亚夏令时要到十月才开始。日期列会随季节移动：悉尼在九月是 +10，在一月是 +11，所以一个深夜的 UTC 瞬间会在那里落到第二天。
日期和时间: Sep 16, 2026 · 09:00 · 上面的时间属于: Asia/Tokyo · 要比较的时区: 3 items
Asia/Tokyo 时间
2026 年 9 月 16 日（星期三），09:00
UTC+09:00，也写作 GMT+9，对应 2026-09-16 00:00 UTC。
UTC: 2026-09-16 00:00 · 相对 UTC 的偏移: UTC+09:00 · 时区名称: GMT+9 · 夏令时: 未实行
东京 09:00 是纽约前一天 20:00、伦敦当天 01:00、奥克兰当天 12:00：同一个瞬间，三个日历日期。
日期和时间: Mar 1, 2026 · 12:00 · 上面的时间属于: Europe/London · 要比较的时区: 3 items
Europe/London 时间
2026 年 3 月 1 日（星期日），12:00
本时区为 UTC（在此显示为 GMT），所以这就是 UTC 瞬间本身。
UTC: 2026-03-01 12:00 · 相对 UTC 的偏移: UTC · 时区名称: GMT · 夏令时: 未实行
三月初三者都还在冬令时：伦敦 0、纽约 −5、柏林 +1。到月底，伦敦和柏林已经调整，纽约还没有；这时一个重复的电话会悄悄偏移一小时。
日期和时间: Jan 16, 2026 · 12:00 · 上面的时间属于: Pacific/Chatham · 要比较的时区: 3 items
Pacific/Chatham 时间
2026 年 1 月 16 日（星期五），12:00
UTC+13:45，实行夏令时，也写作 GMT+13:45，对应 2026-01-15 22:15 UTC。
UTC: 2026-01-15 22:15 · 相对 UTC 的偏移: UTC+13:45 · 时区名称: GMT+13:45 · 夏令时: 实行
查塔姆在一月是 +13:45，所以那里正午是前一天 22:15 UTC——尼泊尔是 +5:45。按整小时保存偏移会把这两个都算错。
先转到 UTC，再转出去：本页就是这么做的。读取所问日期的偏移，减去它得到 UTC，再加上目标时区在同一日期的偏移。经过一个中间量，能让两个时区都改时钟时答案保持一致。
会，因为它在转换的瞬间读取偏移，而不是为每个时区保存固定偏移。这也是页面会打印当年时钟变更的原因：伦敦和纽约在三月相差三周调整，所以重复会议会在一年中的一部分时间里漂移，除非由能感知时区的日历持有。
当时区退出夏令时时，时钟回拨，所以有一小时会发生两次；进入夏令时时，时钟前跳，有一小时从不发生。页面转换它收到的时间，不会多说，因为那些小时里的墙上时间并不对应唯一瞬间。用 UTC 约定时间可以完全避开这个问题。
来自随浏览器打包的 IANA 时区数据库（tzdata），通过内置国际化 API 读取。不下载任何东西，也不发起请求：它就是操作系统显示时钟所用的同一份数据。如果你浏览器没有更新到最新规则，本页会同意你的电脑，而不是新闻。
因为缩写有歧义：IST 是印度标准时间、爱尔兰标准时间和以色列标准时间，而 EST 只表示冬季的 −5。页面接受 IANA 名称，也就是区域和城市——Asia/Kolkata、America/New_York、Asia/Jerusalem——一旦知道你说的是哪个时区，就把缩写作为标签打印出来。
因为时区是行政机构设定的，不是天文学设定的。印度是 +5:30，尼泊尔 +5:45，澳大利亚部分地区 +9:30，纽芬兰 −3:30，查塔姆群岛 +12:45。页面用分钟计算，所以这些不会被四舍五入到最近的小时。
除了时间，还要看日期列，因为加利福尼亚的早晨在东京是第二天；并选择避开时钟变更发生的时段——通常是当地周日凌晨，但不总是。对于任何重复事项，用能感知时区的日历把瞬间保存在 UTC 里，这样只应用一套规则。
最近复核于 2026-09-15.
本页在您的浏览器本地运行，请保留原文件备份；不涉及财务建议。 阅读完整免责声明。
Danfio 中文在线工具