跨国会议定时间
周五上午 10 点要和纽约同事开周会，但对方正在夏令时期间，纽约时间比北京时间晚 12 小时。如果不换算，直接发会议邀请，对方可能在凌晨 3 点收到通知。用本工具输入北京时间和纽约城市名，自动显示对方当地时间和是否受夏令时影响，确保会议时间双方都清醒。
目标快选
—
UTC
—
→
—
UTC
—
24 小时时间带对照 · 找两地共同的工作/会议时间
全球当前时间world clock now
就绪 · 输入时间并选择源/目标时区即可换算
第一节
关于本工具
About国际会议定在纽约时间 14:00，上海团队却算成了凌晨。时区换算工具输入两个城市或 UTC 偏移，直接输出对方当前时间与夏令时状态，无需手动加减。所有计算在浏览器内完成，城市名与偏移量不会离开本地。
使用场景
海外电商抢库存
日本潮牌官网每周三东京时间 9 点限量补货，但国内用户常把北京时间 9 点当日本时间，导致开抢时发现已售罄。用本工具输入东京时间 9 点，自动算出北京时间是 8 点，还能显示当天日本是否已进入夏令时（日本不实行 DST），避免因时差判断错误错失下单窗口。
远程面试定时间
面试官在伦敦，求职者在成都，HR 在深圳，三方需要协调一个 1 小时的面试时段。伦敦当时是夏令时（BST），比北京时间晚 7 小时。用本工具分别输入三个城市当前时间，快速找到三方都处于工作时段（9:00-18:00）的重叠区间，避免反复邮件确认。
国际航班转机衔接
从上海飞法兰克福再转机到里斯本，上海到法兰克福段落地时间显示为当地时间 14:30，但下一程登机牌上写的起飞时间是 16:30（里斯本时间）。两地时差 1 小时且法兰克福和里斯本是否同时实行夏令时？用本工具输入两个城市名，直接显示两地当前时差和 DST 状态，判断转机时间是否够用。
海外直播跟播
澳洲悉尼的博主每晚悉尼时间 20:00 开播，国内运营需要提前半小时上线准备。悉尼在 10 月进入夏令时，与北京时差从 2 小时变为 3 小时。用本工具输入悉尼时间，自动换算成北京时间，并提示当前是否处于夏令时过渡期，避免运营记错时差导致错过开播。
对比矩阵
| 维度 | 本工具 | 主流时区转换站 | 手动查表/计算 |
|---|---|---|---|
| DST 自动处理 | 自动识别并调整夏令时 | 多数支持，但部分需手动选择城市 | 需自行查阅每年 DST 起止日期 |
| 城市覆盖 | 支持全球城市及 IANA 时区名 | 通常只支持主要城市，小城市缺失 | 依赖纸质地图或记忆 |
| UTC 偏移显示 | 同时显示标准偏移与当前偏移 | 部分只显示标准偏移，不区分 DST | 需手动计算偏移差值 |
| 离线可用 | 纯浏览器计算，无需网络 | 依赖网络请求 | 完全离线，但效率低 |
| 输入方式 | 支持城市名 / 时区名 / 缩写混合输入 | 多数只支持城市下拉选择 | 需手动查表换算 |
| 批量对比 | 一次添加多个城市同时对比 | 多数仅支持两两对比 | 需逐对计算 |
第二节
使用指南
Getting Started使用步骤
- 1在「城市 A」输入框键入或粘贴城市名（如 Tokyo），下拉建议列表自动弹出，选中后右侧显示该城市当前本地时间与 UTC 偏移
- 2在「城市 B」输入框重复上一步操作，两城市时差与 DST 状态在中间对比区实时更新
- 3点击任一城市旁的「切换」图标，交换两城市位置，时差方向自动反转
- 4展开底部「DST 详情」面板，查看所选城市夏令时起止日期与偏移变化量
输入输出示例
| 输入 | 输出 | 说明 |
|---|---|---|
| 北京 → 纽约 | 北京（UTC+8）当前时间 14:00 → 纽约（UTC-5，夏令时 UTC-4）当前时间 02:00（次日） | 常规：典型跨时区城市对，覆盖 DST 自动调整，验证夏令时偏移正确性 |
| 东京 → 伦敦 | 东京（UTC+9）当前时间 09:00 → 伦敦（UTC+0，夏令时 UTC+1）当前时间 01:00（同天） | 常规：非夏令时区与夏令时区换算，验证时区偏移计算无误 |
| UTC+14 → UTC-12 | UTC+14 当前时间 23:00 → UTC-12 当前时间 21:00（前日） | 边界：最大正偏移与最大负偏移，验证跨日线日期翻转逻辑 |
| UTC+0 → UTC+0 | UTC+0 当前时间 12:00 → UTC+0 当前时间 12:00 | 边界：同一时区换算，验证输出保持原时间不变，无偏移 |
| 上海 → 乌鲁木齐 | 上海（UTC+8）当前时间 14:00 → 乌鲁木齐（UTC+8）当前时间 14:00 | 易错：两地虽属不同地理经度但使用同一标准时区（中国全境 UTC+8），验证工具不误用地理经度 |
| 悉尼 → 墨尔本 | 悉尼（UTC+11，夏令时）当前时间 10:00 → 墨尔本（UTC+11，夏令时）当前时间 10:00 | 易错：两地同时使用夏令时且偏移相同，验证工具正确处理 DST 同步状态 |
| UTC+5:30 → UTC+8:45 | UTC+5:30 当前时间 08:00 → UTC+8:45 当前时间 11:15 | 边界：非整小时偏移（半小时/45分钟），验证工具支持非标准偏移计算 |
常见错误对照
1.城市名输入不完整，匹配到错误城市
✗ 错误
输入「纽约」✓ 修复
输入「New York」或「America/New_York」工具按 IANA 时区数据库匹配城市名，中文简称可能对应多个时区（如「纽约」在数据库里无直接条目），必须用标准英文名或时区 ID 才能精确匹配。
2.混淆 UTC 偏移与 DST 状态
✗ 错误
认为 UTC+8 的城市全年都是 UTC+8✓ 修复
查询时区分「当前偏移」和「标准偏移」，注意 DST 生效期间偏移会 +1DST 期间实际偏移 = 标准偏移 + 1 小时，工具结果中「当前偏移」已自动包含 DST 调整，但「标准偏移」始终固定，用户需理解两个字段含义。
3.输入错误时区缩写，导致无结果
✗ 错误
输入「CST」✓ 修复
输入「Asia/Shanghai」或明确城市名CST 可指中国标准时间（UTC+8）、美国中部时间（UTC-6）或古巴标准时间（UTC-5），工具无法自动消歧，必须用 IANA 时区 ID 或城市名避免歧义。
4.忽略夏令时转换日期，误判时间差
✗ 错误
查询 3 月 15 日纽约与伦敦时差，直接套用冬季偏移✓ 修复
在工具中分别选择两地具体日期，或查看 DST 转换日历美国 DST 开始于 3 月第二个周日，欧洲 DST 开始于 3 月最后一个周日，两周内两地时差会变化 1 小时，必须指定日期才能得到准确偏移。
5.用 UTC 偏移代替时区 ID 做长期规划
✗ 错误
固定使用 UTC+8 换算所有中国城市✓ 修复
使用「Asia/Shanghai」时区 ID 而非偏移UTC 偏移不包含 DST 规则和历史变更，而时区 ID 包含完整规则。例如乌鲁木齐实际使用 UTC+6 但官方时区是 UTC+8，用偏移会出错。
6.输入城市时遗漏国家或区域限定
✗ 错误
输入「London」✓ 修复
输入「London, UK」或「Europe/London」全球有多个 London（加拿大、美国等），工具数据库可能返回第一个匹配项。加国家或 IANA ID 可确保精确匹配目标城市。
7.混淆 12 小时制与 24 小时制输出
✗ 错误
看到结果「8:00 AM」直接当作 8:00 使用✓ 修复
确认工具输出格式，或切换为 24 小时制显示工具默认按用户浏览器 locale 显示时间格式，若浏览器设为 en-US 则输出 12 小时制，需注意 AM/PM 标记，否则可能误判 12 小时。
第三节
工作原理
How It Works核心公式
目标时间 = 源时间 + (目标时区偏移 - 源时区偏移) + DST调整
变量说明
源时间已知的本地时间，精确到分钟目标时区偏移目标时区相对于UTC的小时数源时区偏移源时区相对于UTC的小时数DST调整夏令时生效时+1，否则为0
示例
北京（UTC+8，无DST）2025年6月15日14:00，换算为纽约（UTC-5，夏令时生效+1→UTC-4）。偏移差 = (-4) - (+8) = -12小时。目标时间 = 14:00 + (-12) = 02:00（同日期）。纽约此时为6月15日02:00（EDT）。
用户输入
本地处理
输出结果
第四节
开发者集成
For Developers5 种主流语言实现，复制即用：
from datetime import datetime, timezone, timedelta
# 获取当前 UTC 时间
utc_now = datetime.now(timezone.utc)
# 定义时区偏移（东京 UTC+9）
tokyo_offset = timedelta(hours=9)
tokyo_time = utc_now + tokyo_offset
# 定义时区偏移（纽约 UTC-5，不考虑夏令时）
ny_offset = timedelta(hours=-5)
ny_time = utc_now + ny_offset
print(f"UTC: {utc_now.strftime('%Y-%m-%d %H:%M')}")
print(f"东京: {tokyo_time.strftime('%Y-%m-%d %H:%M')}")
print(f"纽约: {ny_time.strftime('%Y-%m-%d %H:%M')}")
# 输出示例：
# UTC: 2025-01-15 14:30
# 东京: 2025-01-15 23:30
# 纽约: 2025-01-15 09:30// 获取当前时间并转换为指定时区
const now = new Date();
// 东京（UTC+9）
const tokyoTime = new Intl.DateTimeFormat('ja-JP', {
timeZone: 'Asia/Tokyo',
year: 'numeric', month: '2-digit', day: '2-digit',
hour: '2-digit', minute: '2-digit', hour12: false
}).format(now);
// 纽约（自动处理夏令时）
const nyTime = new Intl.DateTimeFormat('en-US', {
timeZone: 'America/New_York',
year: 'numeric', month: '2-digit', day: '2-digit',
hour: '2-digit', minute: '2-digit', hour12: false
}).format(now);
console.log(`东京时间: ${tokyoTime}`);
console.log(`纽约时间: ${nyTime}`);
// 输出示例：
// 东京时间: 2025/01/15 23:30
// 纽约时间: 2025/01/15 09:30package main
import (
"fmt"
"time"
)
func main() {
now := time.Now().UTC()
// 东京时区（UTC+9，无夏令时）
locTokyo, _ := time.LoadLocation("Asia/Tokyo")
tokyoTime := now.In(locTokyo)
// 纽约时区（自动处理夏令时）
locNY, _ := time.LoadLocation("America/New_York")
nyTime := now.In(locNY)
fmt.Printf("UTC: %s\n", now.Format("2006-01-02 15:04"))
fmt.Printf("东京: %s\n", tokyoTime.Format("2006-01-02 15:04"))
fmt.Printf("纽约: %s\n", nyTime.Format("2006-01-02 15:04"))
// 输出示例：
// UTC: 2025-01-15 14:30
// 东京: 2025-01-15 23:30
// 纽约: 2025-01-15 09:30
}#!/bin/bash
# 使用 date 命令转换时区（需 GNU date）
# 当前 UTC 时间
echo "UTC: $(date -u '+%Y-%m-%d %H:%M')"
# 东京（UTC+9）
TZ='Asia/Tokyo' date '+东京: %Y-%m-%d %H:%M'
# 纽约（自动处理夏令时）
TZ='America/New_York' date '+纽约: %Y-%m-%d %H:%M'
# 输出示例：
# UTC: 2025-01-15 14:30
# 东京: 2025-01-15 23:30
# 纽约: 2025-01-15 09:30use chrono::{Utc, TimeZone, FixedOffset};
fn main() {
let utc_now = Utc::now();
// 东京偏移（UTC+9，固定）
let tokyo_offset = FixedOffset::east_opt(9 * 3600).unwrap();
let tokyo_time = utc_now.with_timezone(&tokyo_offset);
// 纽约偏移（UTC-5，不考虑夏令时；实际应用建议用 chrono-tz）
let ny_offset = FixedOffset::west_opt(5 * 3600).unwrap();
let ny_time = utc_now.with_timezone(&ny_offset);
println!("UTC: {}", utc_now.format("%Y-%m-%d %H:%M"));
println!("东京: {}", tokyo_time.format("%Y-%m-%d %H:%M"));
println!("纽约: {}", ny_time.format("%Y-%m-%d %H:%M"));
// 输出示例：
// UTC: 2025-01-15 14:30
// 东京: 2025-01-15 23:30
// 纽约: 2025-01-15 09:30
}第五节
常见问题
Q & A问输入城市名之后没反应，是不是工具坏了？＋
答
工具是纯前端计算，不依赖网络，所以大概率不是坏了。常见原因是输入的城市名不在内置数据库里，比如只写了「纽约」但数据库里存的是「New York」或「America/New_York」。建议先试下拉菜单里的候选城市，或输入国际标准时区名（如 Asia/Shanghai）。如果还是没反应，检查一下浏览器控制台有没有报错，或者换个浏览器试试。
问为什么同一个城市，不同网站查出来的时区偏移不一样？＋
答
时区偏移不是一成不变的，冬夏令时切换、政府调整时区规则（比如俄罗斯某些地区改过时区）都会导致差异。本工具的时区数据库基于 IANA Time Zone Database，每年更新多次，但如果你查的是历史上的某个日期，不同网站用的数据库版本不同，结果就可能差 1 小时。工具默认显示当前时刻的偏移，如果要查历史日期，记得手动选一下日期。
问我输入北京时间上午 10 点，转成纽约时间为什么显示晚上 10 点？＋
答
这是夏令时导致的。纽约实行夏令时（DST），此时 UTC 偏移是 -4 小时，而北京是 UTC+8 固定不变，两者相差 12 小时，所以北京上午 10 点对应纽约前一天晚上 10 点。如果纽约在冬令时（UTC-5），则相差 13 小时，对应晚上 9 点。工具会自动根据所选日期判断是否处于夏令时，结果区会标注「DST 生效中」字样。
问这个工具能查历史日期或未来日期的时区吗？＋
答
可以。工具支持选择任意日期（包括过去和未来），计算时会自动应用该日期对应的时区规则（含夏令时调整）。注意：未来日期的夏令时生效规则是基于当前已知的时区政策预测的，如果某国未来突然取消或调整夏令时，工具无法提前预知。历史日期则基于 IANA 数据库的完整历史记录，通常可追溯到 1970 年。
问为什么我选的城市在列表里找不到？＋
答
工具内置了全球约 400 个主要城市，覆盖所有时区，但一些小城市或乡镇可能没有收录。可以换成该城市所属的大城市（比如找不到「苏州」用「上海」），或者直接输入时区名（如 Asia/Shanghai）。如果仍然找不到，可能是拼写问题——工具只支持英文城市名，中文名需要先转换成英文。
问这个工具需要联网吗？离线能不能用？＋
答
完全不需要联网。所有时区数据和计算逻辑都在浏览器本地执行，第一次加载后，即使断开网络也可以正常使用。数据包约 200KB，首次加载很快。因此，用这个工具不会向任何服务器发送输入的城市名或时间，隐私方面可以放心。
问同时对比三个以上城市的时区，怎么操作？＋
答
工具默认只支持两个城市之间的时区对比。如果需要同时查看多个城市，可以分多次查询，或者手动记下每个城市相对于 UTC 的偏移（工具结果区会显示），然后自己加减。部分浏览器插件可以实现多城市时区对比，但本工具专注于一对一的精确换算。
问查出来的 UTC 偏移为什么带半小时或 45 分钟？不是整小时？＋
答
虽然大部分时区是整小时偏移，但确实存在非整小时时区，比如尼泊尔是 UTC+5:45，印度是 UTC+5:30，纽芬兰是 UTC-3:30。工具根据 IANA 数据库精确到分钟，不会四舍五入。如果看到偏移不是整小时，说明该城市所在的时区就是如此，不是工具算错了。
隐私保证所有计算与处理均在你的浏览器本地完成，输入数据不会上传服务器，也不会保存或共享。