时区换算

城市↔城市/UTC 偏移/DST

412 次访问

时区换算

24 小时工作时间对照(黄色 = 工作时间 9-17 · 红色 = 当前小时)

全球主要城市当前时间

关于本工具

了解工具定位 · 使用场景 · 对比优势

输入城市名或 UTC 偏移,立即得到两地当前时间、时差以及夏令时生效状态。跨国会议组织者、远程团队协调人、跨境旅行规划者,无需手动推算时区。所有计算在浏览器内完成,城市与时间数据不上传服务器。

使用场景

🌍

跨国会议安排

远程团队分布在纽约、伦敦和上海,要找一个三方都合适的时间开会。本工具同时输入三个城市,自动显示各自的本地时间和 UTC 偏移,并标注 DST 是否生效。省去了手动查时区表、算夏令时的麻烦,直接锁定重叠的工作时段。

✈️

国际航班接机

从东京飞往巴黎的航班落地时间是当地时间 15:30,但接机人在巴黎,需要确认是否与自己的日程冲突。本工具输入出发城市和到达城市,快速换算两地实时时间,避免因时差误解而错过接机或提前数小时干等。

📅

海外考试报名

报名美国线上考试,截止时间是 EST 23:59,但人在北京。本工具输入 UTC-5 的截止时间,自动换算为北京时间(UTC+8)并提示 DST 影响,确保在截止前完成提交,避免因时区换算错误导致报名失败。

💼

跨时区项目交付

项目交付截止时间是 UTC 时间 18:00,团队分散在悉尼、新加坡和旧金山。本工具输入 UTC 时间,同时显示各城市对应本地时间,让每个成员明确自己的 deadline,无需各自翻时区表,减少沟通成本和误判风险。

📱

海外亲友通话

想给在温哥华的家人打视频电话,但不确定对方现在是白天还是深夜。本工具输入对方城市,直接显示当前本地时间和 DST 状态,避开对方休息时段。相比手机自带时钟的单一城市显示,这里可以同时对比两个城市的实时时间。

对比矩阵本工具 vs 竞品 vs 传统方法

维度本工具竞品 A (timeanddate.com)传统方法
数据隐私纯浏览器端计算,城市/时区数据不离开设备查询需发送至服务器,服务器记录 IP 与查询内容依赖人工查阅纸质时区手册或拨打国际长途查询,信息完全暴露给第三方
处理速度输入城市名后,结果即时显示(<1 秒)需加载页面、等待服务器响应,通常 2-5 秒人工翻阅资料或拨打电话,耗时数分钟至数小时不等
离线可用性完全离线,无网络环境也可查询已加载的城市数据必须联网,断网后无法使用任何功能完全离线,依赖手头资料
查询灵活性支持城市名直接搜索,自动匹配时区与夏令时支持城市搜索,但部分功能(如会议时间规划)需多步操作需手动计算 UTC 偏移量,并自行判断夏令时是否生效
数据覆盖范围覆盖全球主要城市及 IANA 时区数据库覆盖全球所有时区及绝大部分城市,数据更新及时受限于手头资料的版本和更新频率,容易遗漏小城市或新时区
夏令时处理自动识别并应用目标城市的夏令时规则,无需手动干预自动识别夏令时,并在结果中明确标注需人工查阅夏令时生效日期,手动加减 1 小时,极易出错
使用成本免费,无任何功能限制基础功能免费,高级功能(如会议邀请、API)需付费订阅购买时区手册或支付国际电话费用,成本较高

使用指南

上手步骤 · 输入输出 · 避坑提示

使用步骤

  1. 在「城市 A」输入框键入或选择第一个城市名称(支持中文/英文),如「Shanghai」
  2. 在「城市 B」输入框键入或选择第二个城市名称,如「New York」
  3. 点击「换算」按钮,页面立即显示两地当前时间、UTC 偏移量及 DST 状态
  4. 查看结果区:左侧为城市 A 时间,右侧为城市 B 时间,中间标注时差(如 +13 小时)
  5. 如需反向查询,交换两城市输入框内容后再次点击「换算」

输入输出示例8 个典型场景,覆盖常规、边界与易错

输入输出说明
北京 → 纽约北京(UTC+8)当前时间 2025-04-01 14:00 → 纽约(UTC-4,夏令时)当前时间 2025-04-01 02:00,相差 12 小时典型场景:中美跨时区查询,含夏令时自动调整
UTC+8 → UTC+0UTC+8 当前时间 2025-04-01 14:00 → UTC+0 当前时间 2025-04-01 06:00,相差 8 小时典型场景:直接使用 UTC 偏移量换算,无城市依赖
伦敦 → 东京伦敦(UTC+1,夏令时)当前时间 2025-04-01 07:00 → 东京(UTC+9)当前时间 2025-04-01 15:00,相差 8 小时典型场景:欧亚主要城市换算,伦敦处于夏令时
UTC-12 → UTC+14UTC-12 当前时间 2025-03-31 22:00 → UTC+14 当前时间 2025-04-01 12:00,相差 26 小时边界 case:最大时区跨度,跨越国际日期变更线
悉尼 → 悉尼悉尼(UTC+11,夏令时)当前时间 2025-04-01 13:00 → 悉尼(UTC+11,夏令时)当前时间 2025-04-01 13:00,相差 0 小时边界 case:同城市查询,验证零时差输出
UTC+5:30 → UTC+5:45UTC+5:30 当前时间 2025-04-01 12:00 → UTC+5:45 当前时间 2025-04-01 12:15,相差 15 分钟边界 case:非整小时偏移(如尼泊尔 UTC+5:45),验证分钟级精度
北京 → 北京北京(UTC+8)当前时间 2025-04-01 14:00 → 北京(UTC+8)当前时间 2025-04-01 14:00,相差 0 小时易错 case:用户误以为不同城市名才能换算,实际同城市也可查
UTC+8 → 上海UTC+8 当前时间 2025-04-01 14:00 → 上海(UTC+8)当前时间 2025-04-01 14:00,相差 0 小时易错 case:UTC 偏移与城市时区相同,新手可能以为有差值

常见错误对照7 个常踩的坑 · 错误 → 修复

1. 混淆 UTC 偏移与夏令时状态

错误
UTC+8 就是北京时间,全年不变
修复
北京时间是 UTC+8,但中国不实行夏令时;欧洲许多国家夏季用 UTC+2(CEST)、冬季用 UTC+1(CET)

UTC 偏移是固定值,DST 是季节性调整;工具输出会同时标注偏移和是否处于 DST 期间,需区分两个字段

2. 输入城市名时带多余空格或全角字符

错误
New York(全角空格) 或 东京(全角括号)
修复
New York(半角空格) 或 东京(无空格)

工具匹配城市数据库时依赖精确字符串;全角字符、多余空格会导致无匹配结果

3. 用城市缩写而非标准 IANA 时区名

错误
EST(美国东部标准时间,但冬季/夏季含义不同)
修复
America/New_York 或 New York

EST/EDT/CST 等缩写歧义大(EST 可指美国东部或澳大利亚东部);工具优先识别 IANA 时区名或完整城市名

4. 忽略 DST 转换日的模糊时段

错误
2024-03-10 02:30 New York 换算到 London
修复
2024-03-10 03:00 New York 换算到 London(避开 02:00-03:00 模糊区间)

DST 开始日凌晨 2 点跳至 3 点,02:00-02:59 不存在;工具会提示该时间无效,需选择有效时刻

5. 把 UTC 偏移直接当城市本地时间

错误
UTC+5:30 就是印度时间,所以印度比 UTC 快 5 小时 30 分
修复
印度标准时间(IST)是 UTC+5:30,但印度不实行 DST,全年固定;若目标城市有 DST,需额外计算

UTC 偏移是理论值,实际本地时间可能因 DST 政策偏离;工具输出的「当前偏移」已包含 DST 调整

6. 输入非标准城市别名或旧名

错误
Peking(北京旧拼写) 或 哥尼斯堡(今加里宁格勒)
修复
Beijing 或 Kaliningrad

工具数据库使用现代标准名称;历史名称、非罗马化拼写、中文音译变体可能不被识别

7. 跨日期线换算时忽略日期变化

错误
UTC+12 的斐济中午 12:00 换算到 UTC-12 的贝克岛,结果写 00:00 同一天
修复
斐济 12:00 → 贝克岛 00:00(前一日)或 次日 00:00(取决于方向)

国际日期变更线两侧日期差一天;工具输出会显示完整日期,需留意日期列而非只看时间

工作原理

公式推导 · 流程图解 · 依据出处

核心公式

T_target = T_source + ΔT_UTC + ΔT_DST

变量说明

  • T_target — 目标城市本地时间
  • T_source — 源城市本地时间
  • ΔT_UTC — 两城市 UTC 偏移量之差(小时)
  • ΔT_DST — 夏令时调整值(0 或 +1 小时)

示例

北京(UTC+8,无 DST)2025-06-15 14:00 → 纽约(UTC-5,夏令时 UTC-4)。ΔT_UTC = (-4) - (+8) = -12 小时,ΔT_DST = 0(北京无 DST)。T_target = 14:00 + (-12) + 0 = 02:00(同日期凌晨)。即北京下午 2 点对应纽约凌晨 2 点。

适用范围

适用于任意两个城市间的时间换算,前提是已知各城市的标准 UTC 偏移及夏令时生效状态。不适用于极地地区(如南极科考站使用特殊时区)或跨国际日期变更线场景(需额外调整日期)。数据来源:IANA Time Zone Database(tzdata)。

原理图

城市 / UTC 偏移用户输入浏览器内计算时差 / DST 判断(纯前端,无服务器)展示结果换算时间 / 偏移输入示例“北京” → “纽约”处理细节时区数据库 + DST 规则输出示例“北京 14:00 → 纽约 02:00”
用户输入 本地处理 输出结果 辅助说明

开发者集成

3 种主流语言 · 复制即用

from datetime import datetime, timezone, timedelta
import pytz

# 城市时区名(IANA 时区数据库)
source_tz = pytz.timezone('America/New_York')
target_tz = pytz.timezone('Asia/Shanghai')

# 当前时间(带源时区)
now = datetime.now(source_tz)
print(f"纽约时间: {now.strftime('%Y-%m-%d %H:%M:%S %Z%z')}")

# 转换到目标时区
target_time = now.astimezone(target_tz)
print(f"上海时间: {target_time.strftime('%Y-%m-%d %H:%M:%S %Z%z')}")

# 计算 UTC 偏移(小时)
utc_offset = now.utcoffset().total_seconds() / 3600
print(f"纽约 UTC 偏移: {utc_offset:+}h")

# 判断夏令时
print(f"纽约当前是否夏令时: {bool(now.dst())}")
package main

import (
	"fmt"
	"time"
)

func main() {
	// 加载时区
	nyLoc, err := time.LoadLocation("America/New_York")
	if err != nil {
		panic(err)
	}
	shLoc, err := time.LoadLocation("Asia/Shanghai")
	if err != nil {
		panic(err)
	}

	// 当前时间(纽约)
	nowNY := time.Now().In(nyLoc)
	fmt.Printf("纽约时间: %s\n", nowNY.Format("2006-01-02 15:04:05 MST"))

	// 转换到上海
	nowSH := nowNY.In(shLoc)
	fmt.Printf("上海时间: %s\n", nowSH.Format("2006-01-02 15:04:05 MST"))

	// UTC 偏移(秒→小时)
	_, offsetNY := nowNY.Zone()
	fmt.Printf("纽约 UTC 偏移: %+dh\n", offsetNY/3600)

	// 夏令时判断(通过偏移与标准偏移比较)
	_, offsetStd := time.Date(2024, 1, 1, 12, 0, 0, 0, nyLoc).Zone()
	isDST := offsetNY != offsetStd
	fmt.Printf("纽约当前是否夏令时: %v\n", isDST)
}
// 使用 Intl API(无需第三方库)
function convertTime(cityFrom, cityTo, date = new Date()) {
    const fromOpts = { timeZone: cityFrom, hour12: false };
    const toOpts = { timeZone: cityTo, hour12: false };

    const fromStr = date.toLocaleString('en-CA', fromOpts); // yyyy-mm-dd HH:MM:SS
    const toStr = date.toLocaleString('en-CA', toOpts);

    console.log(`${cityFrom} 时间: ${fromStr}`);
    console.log(`${cityTo} 时间: ${toStr}`);

    // UTC 偏移(分钟)
    const utcOffsetFrom = -date.getTimezoneOffset();
    const utcOffsetTo = -new Date(date.toLocaleString('en-US', { timeZone: cityTo })).getTimezoneOffset();
    console.log(`${cityFrom} UTC 偏移: ${utcOffsetFrom / 60}h`);
    console.log(`${cityTo} UTC 偏移: ${utcOffsetTo / 60}h`);

    // 夏令时:比较 1 月和 7 月的偏移
    const jan = new Date(date.getFullYear(), 0, 1);
    const jul = new Date(date.getFullYear(), 6, 1);
    const janOffset = -jan.getTimezoneOffset();
    const julOffset = -jul.getTimezoneOffset();
    const isDST = julOffset !== janOffset;
    console.log(`本地当前是否夏令时: ${isDST}`);
}

// 示例:纽约→上海
convertTime('America/New_York', 'Asia/Shanghai');

常见问题

8 个高频疑问

这个时区换算工具,支持哪些城市?能搜到小城市吗?
工具内置了全球主要城市和首都的时区数据,覆盖约 400 个城市,包括所有国家首都、主要经济城市和热门旅游城市。如果搜不到某个小城市,可以用该城市所属国家的主要城市或直接输入 UTC 偏移值来换算。数据基于 IANA Time Zone Database(2024e 版),与操作系统和主流网站同步更新。
为什么我输入北京时间下午 3 点,换算成纽约时间,结果和手机上的时间不一样?
可能原因是夏令时(DST)状态不同。纽约实行夏令时(3 月第 2 个周日到 11 月第 1 个周日),期间比 UTC-5 快 1 小时变成 UTC-4;而北京时间全年固定 UTC+8。如果手机已自动开启「夏令时调整」,但工具默认按当前日期计算 DST,请确认工具界面是否显示了「夏令时」标识。也可以换一个日期再试,比如 1 月 vs 7 月,看结果是否一致。
我用的时候发现结果慢了 1 小时,怎么排查是工具的问题还是我理解错了?
先确认两个城市是否处于同一个大时区(比如中国全境都用北京时间,但新疆实际作息比北京晚 2 小时,工具只算标准时区,不考虑地方作息)。然后检查是否混用了 UTC 偏移和 UTC+8 等表示方式。最简单的方法:搜索「当前时间 [城市名]」对照,如果工具显示的时间与搜索引擎结果一致,说明工具数据没问题。
工具能算出两个城市之间的时差吗?比如北京和伦敦差几个小时?
可以。输入北京和伦敦两个城市名,工具会同时显示两地的当前时间(或指定时间),并在结果区直接标出时差。例如北京是 UTC+8,伦敦在夏令时是 UTC+1,时差 7 小时(北京比伦敦快 7 小时)。如果只输入一个城市,工具默认与 UTC 对比。
这个工具是实时查时间的吗?还是用的固定数据?
工具完全运行在你的浏览器内(纯前端实现),不依赖服务器。首次打开时,工具会加载一份内置的时区规则数据(含 1970-2038 年的 DST 切换规则)。换算时,工具读取你电脑的系统时间作为「当前时间」基准,再根据城市时区规则计算目标时间。因此,工具的结果精度取决于你电脑的时间设置——如果电脑系统时间不准,结果也会偏差。
我断网了,这个工具还能用吗?
能用。因为所有计算和时区数据都在浏览器本地运行,不需要联网请求服务器。断网后打开页面,工具仍然可以正常输入城市名、选择时间、显示换算结果。唯一受影响的是首次打开页面需要加载资源(HTML/JS/CSS),但如果之前已经打开过且浏览器缓存未清,断网后直接使用完全没问题。
工具支持换算到未来或过去的时间吗?比如明年 3 月 15 日纽约几点?
支持。工具通常提供日期选择器,可以手动输入任意日期(一般支持 1970-2038 年范围)。换算时会自动考虑该日期是否处于夏令时期间。例如选明年 3 月 15 日纽约时间,如果那天美国刚进入夏令时(通常在 3 月第 2 个周日),工具会自动应用夏令时偏移。超出 2038 年可能因 32 位时间戳限制无法保证准确。
这个工具和手机自带的「世界时钟」有什么区别?
手机世界时钟通常只显示当前时刻,不能做「指定时间换算」。本工具可以输入任意时间(如「北京时间下午 4 点」),换算成其他城市对应的时间,适合安排跨国会议、航班转机时间计算等场景。另外手机时钟数据更新依赖系统升级,本工具使用独立的数据包,如果手机系统长期未更新导致时区规则过时,本工具可能更准确。
选择 打开 +新窗口 esc关闭