这个工具能做什么
先选择一个基准城市,输入该城市挂钟上显示的日期和时间,点击"转换",同一时刻就会以列表中11个城市各自的当地时间显示出来。每一行包含当地日期、星期、与UTC的偏差(偏移量);若与基准城市日期不同,会标注"前一天/后一天";若正在实行夏令时,也会标出。它适合安排跨国会议、确认海外直播开始时间、判断现在给同事打电话是否合适。时间栏留空时,页面会把设备当前时钟上的数字当作基准城市的时间来换算。
要特别注意:输入的是基准城市的时间,而不是你电脑上的时间。比如你在北京,想知道"纽约上午9点"在各地是几点,就把基准城市设为纽约并输入09:00。
时差计算的原理
各地时间都是协调世界时(UTC)加上一个偏移量。两个城市之间的换算始终是三步:
- 用基准城市的当地时间减去它的偏移量,得到UTC。(东京09:00,偏移+9小时,即UTC 00:00。)
- 把目的地的偏移量加到这个UTC上。(UTC 00:00加上偏移-5小时,得到前一天19:00。)
- 若越过了午夜,日期也要相应前移或后移。
麻烦在于,同一个城市的偏移量并非全年不变。本页面没有存放固定的偏移量表,而是通过标准的Intl.DateTimeFormat接口,向浏览器询问该城市的钟表在被换算的那一刻显示几点几分,再由差值得出偏移量。因此结果取决于你的浏览器所带的IANA时区数据库在该日期的规则。
IANA时区名称与缩写的区别
菜单中的每个城市都用"区域/地点"形式的IANA时区标识符保存,例如America/New_York、Europe/London、Asia/Kolkata。标识符指的是一个地点连同它历次规则变更的完整历史;缩写则容易产生歧义,比如CST既可指北美中部标准时间,也可指中国标准时间,IST可能指印度、爱尔兰或以色列。分享时间时,写明城市名或"该日期相对UTC的偏移"可以避免误会。另外,一个国家可能跨越多个时区,"纽约"代表的是美国东部时区,而不是整个美国。
各城市的UTC偏移(参考表)
下表在页面构建时按与工具相同的思路,由时区数据库计算而成。表中取全年前后各一天,即2026年1月15日和7月15日,并把各城市与北京作比较。夏令时规则由各国政府制定,可能调整,所以表格仅作示例;重要的安排请以官方信息或最新时区数据为准。
| 城市 | IANA时区 | 1月15日 | 7月15日 | 与北京的差(1月) | 与北京的差(7月) | 夏令时导致变动 |
|---|---|---|---|---|---|---|
| 首尔 | Asia/Seoul | UTC+9 | UTC+9 | +1 | +1 | 否 |
| 东京 | Asia/Tokyo | UTC+9 | UTC+9 | +1 | +1 | 否 |
| 北京 | Asia/Shanghai | UTC+8 | UTC+8 | 0 | 0 | 否 |
| 曼谷 | Asia/Bangkok | UTC+7 | UTC+7 | -1 | -1 | 否 |
| 新德里 | Asia/Kolkata | UTC+5:30 | UTC+5:30 | -2.5 | -2.5 | 否 |
| 迪拜 | Asia/Dubai | UTC+4 | UTC+4 | -4 | -4 | 否 |
| 伦敦 | Europe/London | UTC+0 | UTC+1 | -8 | -7 | 是 |
| 巴黎 | Europe/Paris | UTC+1 | UTC+2 | -7 | -6 | 是 |
| 纽约 | America/New_York | UTC-5 | UTC-4 | -13 | -12 | 是 |
| 洛杉矶 | America/Los_Angeles | UTC-8 | UTC-7 | -16 | -15 | 是 |
| 悉尼 | Australia/Sydney | UTC+11 | UTC+10 | +3 | +2 | 是 |
差值列表示"该城市时钟 − 北京时钟",单位为小时。例如-14表示北京为正午时,该城市是前一天22:00。最后一列为"是"的城市,1月和7月的偏移量不同,也就是实行夏令时。悉尼位于南半球,所以在北半球的冬季,它的钟表反而拨快了。新德里的+5:30说明偏移量并不总是整数小时。
核算过的计算示例(用同样的Intl方法验证)
示例1. 东京2026年1月15日(周四)09:00即UTC 00:00。此时伦敦是同一个周四的00:00,悉尼是周四11:00,纽约则是1月14日(周三)19:00。纽约日期不同,工具会标为"前一天"。
示例2. 伦敦2026年7月15日(周三)12:00等于UTC 11:00,因为7月伦敦处于夏令时(UTC+1)。此时东京20:00、新德里16:30、纽约07:00、洛杉矶04:00,都是同一个周三。对纽约来说07:00开始偏早,发邀请之前就能发现这类问题。
示例3. 洛杉矶2026年1月15日(周四)20:00是周五UTC 04:00。此时东京为周五13:00,新德里为周五09:30,也就是加州的晚上在日本已经是第二天下午。
容易踩的坑与局限
- 切换时段的错位。 各地拨动时钟的日期不同,一年里会有几周两城之间的时差与平时相差1小时。把例会固定在某城市的同一钟点,其他与会者看到的时间就可能偏移一小时。切换日前后请重新核对。
- 不存在的时刻与出现两次的时刻。 时钟拨快当天会跳过一小时,拨慢当天某一小时会出现两次。输入被跳过的时刻时,工具会调整为有效时间并给出提示;对出现两次的时刻,仅凭当地时间无法确定唯一瞬间,页面只取其中一种解释,不会警告。请避开这些时段,或直接用UTC表示。
- 城市不等于国家。 这11个城市只是各自时区的代表,同一国家的其他地方可能使用不同的偏移量。
- 数据来自浏览器。 工具使用浏览器内置的时区数据,随浏览器更新而更新。很久以前或很遥远的日期,可能受到浏览器数据尚未纳入的规则变动影响。
- 夏令时的判断方式。 "夏令时"标记是把当天的偏移量与同年1月、7月的偏移量比较后推断的。有些地区曾调整或取消夏令时,特殊情况请另行核实。
- 不适合用于法定期限。 机票、合同、申报截止时间等,应以官方文本及其所指明的时区为准。
如何使用换算结果
- 多地参会时,先换算一次,浏览所有人的当地时间,看是否有人落在合理工作时间之外;若有,就把基准时间每次挪动一小时再换算,直到最不利的那位也能接受。
- 点击"复制结果"把整个列表粘贴到聊天或邀请里。每行含日期、星期和偏移量,对方无需自己计算,日期不同的城市还带有"前一天/后一天"标记。
- 直播、截止时间这类一次性安排,请输入具体日期,用当天的偏移量来核对;定期安排则要在各地区切换夏令时的前后重新检查。
常见问题
会考虑夏令时吗?
会。偏移量由浏览器中的时区数据按你输入的日期得出,实行夏令时的城市会自动调整,并在生效期间标注。只有切换当晚被跳过或重复的钟点需要留意。
不输入时间会怎样?
页面把设备当前时钟上的数字当作基准城市的挂钟时间来换算。如果你所在的地方和基准城市不同,请直接输入时间,或把基准城市设为你所在的城市。
为什么同样两个城市,时差会随季节变化?
因为只有部分地区拨动时钟。当一方拨动一小时而另一方没有动时,时差就增加或减少一小时,而各地切换的日期不同,这种错位会持续一段时间。
UTC和GMT是一回事吗?
日常使用中两者显示的钟点相同。严格来说,GMT起源于格林尼治子午线上的平均太阳时,UTC则是借助原子钟维持的现行标准。英国冬季用GMT,夏季用UTC+1的英国夏令时。
为什么有的偏移量带30分钟?
有些国家把本国标准时间定在与整点偏差30分钟或45分钟的位置,表中印度的UTC+5:30就是一例。本工具直接使用数据库里的数值,所以带分钟的偏移量也能正确计算。