这个转换器怎么计算
转换器把你输入的日期和时间当作基准城市墙上时钟显示的时间,先换算成 UTC(协调世界时)上的一个确定时刻,再求出同一时刻目标城市的时钟显示几点。 列表中的每个城市都对应一个 IANA 时区标识,比如 America/New_York、Asia/Kolkata。浏览器内置的 Intl.DateTimeFormat 使用 IANA 时区数据库, 返回所选日期在该时区适用的 UTC 偏移量。由于偏移量取决于日期,所以工具并不是简单地加减一个固定的小时数,而是知道某个城市在这一天是否处于夏令时。
列表一共有 25 个城市,覆盖东亚、南亚、中东、欧洲、南美、北美(包括阿拉斯加和夏威夷)以及大洋洲的主要地区。它只是常用城市的样本,并非完整名录。 找不到你的城市时,请选择同一时区的城市:华盛顿与纽约同一时间,温哥华与洛杉矶同一时间。
局限:结果依赖浏览器或操作系统自带的时区数据。如果某国最近修改了规则而你的设备没有更新,显示的可能仍是旧规则。很远的未来日期是按"现行规则继续有效"来计算的, 而各国政府可能调整规则。机票、合同、截止时间、考试等重要事项,请务必以发布机构标注的当地时间为准。
UTC、偏移量与时差的由来
地球大约每24小时自转360度,经度每相差15度,太阳时大约相差1小时。为了避免每个城镇各用一套时间,世界被划分为标准时区,通常用相对于 UTC 的偏移量表示。 UTC 取代了旧的天文基准格林尼治平均时(GMT),成为民用时间的基础;日常使用中二者常被视为同一个数值,不过英国冬季用 GMT,夏季用 UTC+1 的夏令时。 UTC-5 表示比 UTC 慢5小时,UTC+9 表示快9小时。目前实际使用的偏移量范围是 UTC-12 到 UTC+14。
偏移量也不一定是整数小时。在这份列表中,带有非整点偏移的城市是:新德里 (UTC+5:30)。世界上还有尼泊尔(UTC+5:45)这样差45分钟的例子。转换器以分钟为单位计算, 所以这类时差也是正确的:在下面1月的例子里,纽约是9:00时,新德里是19:30。
25个城市的 UTC 偏移量(构建时计算)
下表是生成本页时,根据构建环境里的时区数据算出来的,没有任何手工输入的数字。表中比较的是 2026 年1月15日和7月15日的偏移量:两个值不同的城市,当年实行夏令时。25 个城市中有 12 个实行,13 个不实行。最后一列列出该城市在 2026 年偏移量发生变化的时刻,写的是变化之后的当地日期和时间。 这是根据数据计算出的结果,不是官方公告;官方日期可能调整,需要时请向相关国家政府确认。
| 城市 | IANA 时区 | 1月15日 | 7月15日 | 2026 年偏移量变化时刻 |
|---|---|---|---|---|
| 首尔 | Asia/Seoul | UTC+9 | UTC+9 | 无 |
| 东京 | Asia/Tokyo | UTC+9 | UTC+9 | 无 |
| 北京 | Asia/Shanghai | UTC+8 | UTC+8 | 无 |
| 新加坡 | Asia/Singapore | UTC+8 | UTC+8 | 无 |
| 曼谷 | Asia/Bangkok | UTC+7 | UTC+7 | 无 |
| 雅加达 | Asia/Jakarta | UTC+7 | UTC+7 | 无 |
| 新德里 | Asia/Kolkata | UTC+5:30 | UTC+5:30 | 无 |
| 迪拜 | Asia/Dubai | UTC+4 | UTC+4 | 无 |
| 莫斯科 | Europe/Moscow | UTC+3 | UTC+3 | 无 |
| 伊斯坦布尔 | Europe/Istanbul | UTC+3 | UTC+3 | 无 |
| 开罗 | Africa/Cairo | UTC+2 | UTC+3 | 2026-04-24 01:00 (UTC+2 → UTC+3); 2026-10-29 23:00 (UTC+3 → UTC+2) |
| 巴黎 | Europe/Paris | UTC+1 | UTC+2 | 2026-03-29 03:00 (UTC+1 → UTC+2); 2026-10-25 02:00 (UTC+2 → UTC+1) |
| 柏林 | Europe/Berlin | UTC+1 | UTC+2 | 2026-03-29 03:00 (UTC+1 → UTC+2); 2026-10-25 02:00 (UTC+2 → UTC+1) |
| 伦敦 | Europe/London | UTC+0 | UTC+1 | 2026-03-29 02:00 (UTC+0 → UTC+1); 2026-10-25 01:00 (UTC+1 → UTC+0) |
| 里斯本 | Europe/Lisbon | UTC+0 | UTC+1 | 2026-03-29 02:00 (UTC+0 → UTC+1); 2026-10-25 01:00 (UTC+1 → UTC+0) |
| 圣保罗 | America/Sao_Paulo | UTC-3 | UTC-3 | 无 |
| 布宜诺斯艾利斯 | America/Argentina/Buenos_Aires | UTC-3 | UTC-3 | 无 |
| 纽约 | America/New_York | UTC-5 | UTC-4 | 2026-03-08 03:00 (UTC-5 → UTC-4); 2026-11-01 01:00 (UTC-4 → UTC-5) |
| 芝加哥 | America/Chicago | UTC-6 | UTC-5 | 2026-03-08 03:00 (UTC-6 → UTC-5); 2026-11-01 01:00 (UTC-5 → UTC-6) |
| 丹佛 | America/Denver | UTC-7 | UTC-6 | 2026-03-08 03:00 (UTC-7 → UTC-6); 2026-11-01 01:00 (UTC-6 → UTC-7) |
| 洛杉矶 | America/Los_Angeles | UTC-8 | UTC-7 | 2026-03-08 03:00 (UTC-8 → UTC-7); 2026-11-01 01:00 (UTC-7 → UTC-8) |
| 安克雷奇 | America/Anchorage | UTC-9 | UTC-8 | 2026-03-08 03:00 (UTC-9 → UTC-8); 2026-11-01 01:00 (UTC-8 → UTC-9) |
| 檀香山 | Pacific/Honolulu | UTC-10 | UTC-10 | 无 |
| 奥克兰 | Pacific/Auckland | UTC+13 | UTC+12 | 2026-04-05 02:00 (UTC+13 → UTC+12); 2026-09-27 03:00 (UTC+12 → UTC+13) |
| 悉尼 | Australia/Sydney | UTC+11 | UTC+10 | 2026-04-05 02:00 (UTC+11 → UTC+10); 2026-10-04 03:00 (UTC+10 → UTC+11) |
夏令时因地区而异
夏令时是在温暖季节把时钟拨快、之后再拨回的制度,没有全球统一的规则。美国和加拿大的大部分地区以及本列表中的欧洲国家都实行。南半球的夏季在12月至2月, 所以悉尼和奥克兰在北半球的冬天处于夏令时,拨钟的方向正好相反。日本、中国、新加坡、印度、泰国、印度尼西亚、阿联酋等许多地方并不实行,夏威夷也是如此。 有些国家取消了夏令时或把时间固定下来:上表显示莫斯科、伊斯坦布尔、圣保罗在 2026 年没有偏移量变化。
实际使用中要记住:两个城市之间的时差并非全年不变。美国和欧洲通常在不同的周末拨钟,所以在春季和秋季有几周,纽约与伦敦的时差会比平时少1小时。 具体的切换时刻请看上表,想核对某一天就在转换器的日期栏里试一试。
用与转换器相同的代码算出的示例
示例 1:隆冬,2026 年1月15日纽约 9:00。伦敦是 2026-01-15 14:00 (UTC+0),东京是 2026-01-15 23:00 (UTC+9),新德里是 2026-01-15 19:30 (UTC+5:30),悉尼是 2026-01-16 01:00 (UTC+11)。 请注意悉尼已经是第二天,而新德里带有30分钟的尾数。
示例 2:盛夏,2026 年7月15日纽约 9:00。伦敦是 2026-07-15 14:00 (UTC+1),东京是 2026-07-15 22:00 (UTC+9),新德里是 2026-07-15 18:30 (UTC+5:30),悉尼是 2026-07-15 23:00 (UTC+10)。 与冬季示例相比,伦敦不同是因为英国在夏令时;悉尼不同是因为此时纽约在夏令时而悉尼是标准时间。东京不实行夏令时,它的数值只因纽约的变化而变化。
示例 3:2026 年3月15日纽约 9:00。按构建本页时的数据,伦敦是 2026-03-15 13:00 (UTC+0),时差为4小时(1月是5小时)。这个时间点美国和欧洲的切换时机并不同步。 在这个季节安排会议时,请务必用具体日期试算。
常见错误
- 死记一个固定时差:"纽约比伦敦慢5小时"在一年中的大部分时间成立,但并非全年。务必同时核对日期。
- 把一个国家当成一个时区:美国本土有4个时区,俄罗斯更多,澳大利亚和加拿大也有多个。要选对城市:芝加哥属中部时间,丹佛属山地时间,洛杉矶属太平洋时间。
- 以为大国一定有多个时区:中国全境只使用一个标准时间,即北京时间(UTC+8)。
- 忽略切换当天:春季切换日有一个小时不存在,比如纽约当天的 02:30 会被跳过;秋季同一个小时会出现两次。不存在的时间会提示错误,重复的时间只会按其中一种计算,所以在切换前后要手动核对。
- 邀请里只写"上午10点":对方可能按自己的时区理解。请务必注明时区名称或 UTC 偏移量。
跨时区安排日程的实用建议
每个邀请都要写明时区,并使用日历应用的时区栏,这样每位参与者看到的是自己的当地时间。定期会议要注意拨钟时期:固定在纽约每周9:00的会议, 在春季和秋季的几周里,可能在伦敦同事的日历上相差1小时。截止时间写成"UTC 23:59"这样不受夏令时影响的形式最稳妥。服务器日志和数据库建议统一存 UTC,只在显示时转换。 航班的起飞和到达时间都用当地时间表示,夜间航班的日期可能会变。在这个转换器里输入日期,就能看到日期的变化。
如果想计算距离某个日子还有几天,而不是换算时刻,可以用D-day 倒计时计算器。想查看其他城市的时间,请见时区转换器; 想了解地球自转为何带来时差,可以阅读地球科学小知识。
常见问题
日期变化时会显示吗?
会。转换结果落在第二天或前一天时会有提示,所有城市的表格里也会并列显示各城市的当地日期。
夏令时会自动计入吗?
会。你输入的日期决定每个城市使用的偏移量,当天处于夏令时的城市按夏季偏移量计算,结果的小标签会显示所用的偏移量。
用的是哪个时区数据库?
通过浏览器标准 Intl API 使用的 IANA 时区数据库。每个城市对应一个标识,如 Europe/London、Pacific/Auckland。长期未更新的旧设备可能仍使用过时的规则。
有差30分钟的时区吗?
有。印度是 UTC+5:30,尼泊尔是 UTC+5:45,澳大利亚部分地区是 UTC+9:30。转换器以分钟为单位计算,因此可以处理这些偏移量。
UTC 和 GMT 一样吗?
日常安排中可以视为同一个数值。UTC 是基于原子钟的现行标准,GMT 是源自天文观测的旧基准。英国冬季用 GMT,夏季用 UTC+1 的夏令时。