世界时间 · 全球各国首都与主要城市精确时间

--:--:--
加载中…
54实时时间卡片
19UTC 偏移覆盖
8常见问答
1实时刷新

实用工具 6 个可用

从开发者常遇到的时间戳转换,到跨国团队安排会议的时差计算, 再到旅行前的时区换算——这六个工具覆盖了与时间打交道时最常遇到的场景, 全部在浏览器端完成运算,不上传任何数据。点击任意卡片即可打开工具。

按大洲浏览 6 大洲

每个大洲的时区分布都不相同——非洲东西横跨但几乎不实行夏令时, 欧洲各国虽小却有着密集的时差变化。下表列出了各大洲的国家数量、 UTC 偏移范围与夏令时实行情况。

大洲国家/地区UTC 范围夏令时
亚洲 48 个 UTC+2 ~ UTC+12 少数国家实行(如黎巴嫩、以色列)
欧洲 44 个 UTC+0 ~ UTC+5 除冰岛外,欧盟全境实行
非洲 54 个 UTC-1 ~ UTC+4 仅埃及、摩洛哥等少数国家
美洲 35 个 UTC-10 ~ UTC-2 美国、加拿大、智利、巴拉圭等
大洋洲 16 个 UTC+8 ~ UTC+14 澳大利亚、新西兰部分州
南极洲 无常住居民 UTC-12 ~ UTC+12 各科考站自定
快速跳转

想去哪个大洲看看?

点击下方任一大洲,快速定位到对应的国家与城市时间卡片。 每个大洲的时区跨度不同,跨洲会议建议先看时差再定时段。

世界各国的精确时间 12 个代表国家

中国和印度人口加起来占全球三分之一,但两国的时间相差 2.5 小时——不是因为距离太远, 而是印度选择了 UTC+5:30 这个「折中」偏移。类似的还有尼泊尔(UTC+5:45)、 缅甸(UTC+6:30)。每个国家时区选择的背后,往往藏着地理、政治或历史的考量。

各国首都的精确时间 12 个首都

提到澳大利亚,你可能先想到悉尼或墨尔本。但它的首都是堪培拉——一个为首都身份专门规划出来的城市。 类似的还有巴西的巴西利亚、土耳其的安卡拉。这些「非典型首都」的存在, 也意味着它们的时间可能与国内最大城市分处不同时区。

世界主要城市的精确时间 18 个城市

国际金融市场的节奏,由三座城市的时钟决定:纽约、伦敦、东京。 当纽约的交易员在下午 4 点按下收盘键时,东京的交易员还在睡梦中—— 而此时伦敦已进入深夜。这三座城市的时差,构成了全球资本流动的「呼吸节奏」。

具有特殊地位地区的精确时间 12 个地区

同样是中国的一部分,香港的 IANA 时区代码是 Asia/Hong_Kong, 北京是 Asia/Shanghai——虽然时间完全一致。 相比之下,美国海外领地关岛的时间就与本土完全不同——关岛比纽约快 15 小时, 几乎是「隔了一天」。

计时体系的基础知识 6 个核心概念

我们每天看着手机上的时间过日子,但很少有人会问:这一秒到底有多长?它由什么定义? 这个问题的答案,牵扯到铯原子的振荡频率、地球自转的微小变化, 以及国际间长达数十年的协调谈判。

主要城市在 UTC 偏移轴上的位置
从 UTC−12 到 UTC+14,跨度为 26 小时。以下为主要城市在无夏令时期间的静态偏移。
洛杉矶UTC−8
纽约UTC−5
圣保罗UTC−3
伦敦UTC+0
迪拜UTC+4
新德里UTC+5:30
北京UTC+8
东京UTC+9
悉尼UTC+10
奥克兰UTC+12
UTC 协调世界时 Coordinated Universal Time
1967 年,13 个国家的代表在巴黎签署了一份文件,重新定义了「秒」——不再依赖地球自转, 而是基于铯-133 原子在两个能级间跃迁时辐射的电磁波周期。 这个决定,为后来 UTC 的诞生奠定了基础。如今全球所有计算机的「一秒」, 本质都来源于这个物理定义。
GMT 格林尼治时间 Greenwich Mean Time
1884 年,41 个国家的代表在华盛顿开了数周的会,最终投票决定:以伦敦格林尼治天文台的 子午线作为全球经度起点。这次投票并不轻松——法国代表坚持要用巴黎子午线, 直到 1911 年才勉强接受。GMT 从此成为全球时间基准,直到 1972 年被 UTC 取代。
TAI 国际原子时 International Atomic Time
你手机上的时间,可能和地球另一端某台原子钟的时间差了几十纳秒。为了消除这个差异, 国际计量局会定期收集全球约 400 台原子钟的数据,加权平均后得到「国际原子时」。 这是一个纯粹基于物理振荡的时标——它不关心地球转得快还是慢, 只关心铯原子的振荡频率。
闰秒 Leap Second
闰秒的出现,是因为地球自转速度在缓慢减慢,而原子钟的振荡频率极为稳定。 每次闰秒都会给计算机系统带来麻烦——下面这条时间线记录了它从诞生到被决定终止的全过程。
1972首次引入闰秒,UTC 与 TAI 的差距开始被主动调整
2012Reddit / Mozilla / LinkedIn 服务器在 23:59:60 出现 CPU 飙升
2016Cloudflare 部分 DNS 解析出现异常
2022国际度量衡大会通过决议:最迟 2035 年前取消
2035闰秒机制计划正式终止
时区与 UTC 偏移 Time Zone & Offset
从北京飞到乌鲁木齐,你的手表不用调整;但如果站在当地正午的太阳下, 会发现钟表显示的是下午两点。这就是统一时区的代价。全球共有 38 种不同的 UTC 偏移, 其中有 5 个是非整点偏移——它们大多是为了让当地正午更接近太阳最高的时刻。
38种 UTC 偏移
5个非整点偏移
−12 ~ +14偏移范围
夏令时 DST Daylight Saving Time
1916 年 4 月 30 日晚上 11 点,德意志帝国的钟表被集体拨快一小时—— 这是人类历史上第一次全国范围的夏令时实践,目的是为战时节省煤炭。 随后英国、法国、美国相继跟进。一百多年后,这项制度的争议从未停止: 2019 年欧盟议会投票通过了取消决议,但至今仍未落地执行。

行业时间同步要求 6 个行业

如果你的银行卡交易记录显示时间为 14:32:08.123456, 而服务器另一端的记录是 14:32:08.123457, 这一微秒的差异可能会让这笔交易的时间戳排序出现争议。在高频交易领域, 这样的争议每天都会发生数百次。

金融交易Financial Trading
≤ 100 微秒
欧盟 MiFID II RTS 25 规定高频交易的时间戳精度须达 100 微秒以内。 2012 年骑士资本因时钟同步故障,45 分钟内损失 4.4 亿美元。
电信 5GTelecom / 5G
± 1.5 微秒
TDD 制式的 5G 基站依靠精确时间同步来划分上下行时隙, 一旦失步,相邻基站会互相干扰,用户会感到通话中断或数据卡顿。
电力系统Power Grid
≤ 1 微秒
电网里的同步相量测量装置需要在 1 微秒内对齐时间戳, 才能准确反映整张电网的实时状态。 2003 年北美大停电的调查报告曾提及时间同步异常的隐患。
数据中心Data Center
≤ 1 毫秒
分布式数据库依赖毫秒级的时间戳来确定事务顺序。 Google Spanner 甚至专门设计了 TrueTime API, 用 GPS 和原子钟组合来保证跨洲一致性。
铁路调度Rail Transport
≤ 1 秒
列车控制系统对时间精度要求相对宽松,1 秒级即可满足安全运行。 但欧洲 ETCS 标准要求全线所有信号设备使用同一时钟源。
广播电视Broadcasting
≤ 100 毫秒
数字电视单频网中,多台发射机必须在 100 毫秒内同步发送同一信号, 否则观众会在画面上看到重影,或在收听时听到回声。

时间同步精度等级对照 Stratum 0–4

你家路由器的时间,可能比标准时间慢几十毫秒——这通常无关紧要。 但对 5G 基站来说,如果时间偏差超过 1.5 微秒,相邻基站就会互相干扰; 对电力系统来说,如果时间偏差超过 1 微秒,同步相量测量就会失效。

等级含义与典型设备典型偏差适用场景
Stratum 0
基准时钟设备本身——铯原子钟、铷原子钟、GPS 卫星搭载的原子钟。不直接接入网络
± 10⁻¹⁰ 秒
国家时间标准、卫星导航
Stratum 1
直接与 Stratum 0 相连的服务器,通常配有 GPS 或北斗接收机,如国家授时中心的时间服务器。
< 1 微秒
国家级时间源、权威 NTP
Stratum 2
通过网络从 Stratum 1 同步时间。多数公共 NTP 服务器(如 ntp.aliyun.com)位于此层。
1 – 10 微秒
电信骨干、金融核心
Stratum 3
与 Stratum 2 同步。企业内部自建的 NTP 服务器通常处于这一层级。
10 – 100 微秒
数据中心、企业网络
Stratum 4
与 Stratum 3 同步。普通办公电脑、家用路由器自动获取时间时通常位于此层。
100 微秒 – 1 毫秒
办公设备、家用网络

数据来源与核验

本站所有时间数据均由浏览器本地实时计算得出,不依赖任何服务端接口。 以下是各项数据的具体来源,可供独立核验。

时区规则 · IANA tzdata
采用互联网号码分配局(IANA)维护的 Time Zone Database。这是全球时区信息的权威标准,包含历史时区变更、夏令时切换规则及各地 UTC 偏移。
时间计算 · Intl.DateTimeFormat API
通过浏览器内置的 Intl 国际标准化接口,结合您的设备系统时钟,在本地实时推导每一座城市的当地时间,误差通常在 1 秒以内。
农历数据 · 紫金山天文台历法
农历显示基于中国科学院紫金山天文台发布的《中国天文年历》算法,覆盖 1900 至 2100 年,包含闰月与干支纪年。
日出日落 · NOAA 太阳位置算法
采用美国国家海洋和大气管理局(NOAA)发布的太阳位置算法,基于城市经纬度计算日出、日落与日照时长,误差通常在 ±1 分钟内。

常见问题 8 条

整理自用户常提的疑问,涉及夏令时、时区规则、时间戳与闰秒等话题。 如果这里没找到你想要的答案,欢迎在页面底部留言告诉我们。

夏令时是什么?为什么有些国家要调整时钟?

同样是在 6 月的下午 6 点,巴黎的天还很亮,而北京已经开始天黑。这就是夏令时带来的差异——不是因为纬度不同,而是因为法国在 3 月的最后一个周日把时钟往前拨了 1 小时。

目前全球仍在实行夏令时的国家约有 70 个,主要集中在欧洲、北美和部分南美国家。欧盟 27 个成员国中,除冰岛外全部使用夏令时;而亚洲、非洲的大部分国家已经放弃这项制度。中国自 1992 年起不再实行夏令时——最后一次调整发生在 1991 年 9 月 15 日。

欧盟议会在 2019 年投票通过了取消夏令时的决议,但需要各成员国协调,至今仍未落地执行。如果最终落地,将是自 1916 年以来的重大变革。

为什么不同网站显示的同一城市时间会略有差异?

2023 年 3 月,黎巴嫩政府突然宣布推迟夏令时生效时间,导致全国陷入「两个时间」的混乱——机场、银行、学校各行其是。当时许多国际时间网站都显示错误的时间,直到几天后才更新。

这类问题的根源在于:时区数据库不是一成不变的。IANA 的 tzdata 数据库每年会更新数次,某些国家的时区规则、夏令时起止日期会临时调整。使用旧版本数据的网站,就会显示过时的信息。

此外还有两个次要原因:一是部分网站通过服务端 API 获取时间,网络延迟会体现在显示结果上;二是如果您的设备系统时钟本身有偏差,本地渲染的时间也会跟着不准。本站使用浏览器内置的 IANA 数据库直接计算,不经过服务端,能最大程度避免前两类问题。

为什么有些国家使用半小时或 45 分钟的时区偏移?

印度的标准时间是 UTC+5:30,而不是 UTC+5 或 UTC+6。这个「折中」的选择背后有一段历史:印度独立后,孟买(UTC+5 区域)和加尔各答(UTC+6 区域)的时差一直困扰着铁路调度。1955 年,印度政府决定取中间值,让全国统一使用 UTC+5:30。

类似的情况还有:

  • 尼泊尔 UTC+5:45——全球唯一的 45 分钟偏移,据说是为了凸显「不是印度的一部分」
  • 缅甸 UTC+6:30——介于孟加拉与泰国之间
  • 澳大利亚中部 UTC+9:30——与东海岸和西海岸都不同
  • 伊朗 UTC+3:30——位于中东标准时区之间

这些非整点偏移的共同好处是:让当地正午时间更贴近太阳到达最高点的时刻,使作息与日照更协调。

中国这么大,为什么全国只用一个时区?

1949 年之前,中国其实有 5 个时区——从「昆仑时区」(UTC+5:30)到「长白时区」(UTC+8:30),每个时区对应一条经度带。这套制度源自民国时期,主要服务于铁路和电报系统。

1949 年新中国成立后,为了便于行政管理,全国统一采用北京时间(UTC+8,Asia/Shanghai)。这一决定在当时是合理的——跨时区通信、调度、记账都简化了。但代价也很明显:新疆、西藏等西部地区,日出日落时间与北京时间相差极大。在乌鲁木齐,冬季日出可能要等到北京时间早上 8 点以后。

所以新疆民间一直有「乌鲁木齐时间」(UTC+6)的说法,部分政府机关和学校也在日常工作中使用。但正式场合和时间戳仍然统一使用北京时间。

时区和 UTC 偏移有什么区别?

这两个词经常被混着用,但它们描述的是不同的东西。

时区(Time Zone)是一个地理和行政概念。它用 IANA 名称表示,比如 Asia/ShanghaiAmerica/New_YorkUTC 偏移(UTC Offset)是具体的数字差值,比如 UTC+8UTC−5

关键区别是:一个时区可以对应多个 UTC 偏移。比如 America/New_York,冬季是 UTC−5,夏季因夏令时变成 UTC−4。而 Asia/Shanghai 全年都是 UTC+8。所以在程序里存储时间时,用 IANA 时区名比存 UTC 偏移更可靠

Unix 时间戳是什么?为什么要用它?

假设你开发一个跨国应用,用户在纽约、伦敦、东京同时下单。如果你把订单时间记录为「2026-09-19 14:32:08」,事后就必须知道「这个时间是指哪个城市的 14:32」,才能正确排序。而 Unix 时间戳解决的就是这个问题——它是一个纯粹的整数,不携带任何时区信息

Unix 时间戳的定义是:从 1970 年 1 月 1 日 00:00:00 UTC 起,到某一时刻共经过了多少秒。全世界任何一台计算机,对同一个时间戳的理解都完全一致。系统日志、数据库时间字段、API 请求参数,都大量使用它。

有一个值得一提的历史遗留问题:32 位有符号整数能表示的最大时间戳对应 2038 年 1 月 19 日 03:14:07 UTC。过了这一刻,使用 32 位存储的系统会出现溢出。现代操作系统和服务已普遍改用 64 位,「2038 问题」正在逐步被消解,但仍有大量嵌入式设备尚未升级。

什么是闰秒?为什么国际社会要取消它?

自 1972 年到现在,全球总共加过 27 次闰秒——平均每 1.5 年一次。每次闰秒都会给计算机系统带来麻烦:2012 年 Reddit、Mozilla、LinkedIn 的服务器在那一分钟内出现 CPU 使用率飙升;2016 年底的闰秒则导致 Cloudflare 的部分 DNS 解析出现异常。

闰秒的出现,是因为地球自转速度在缓慢减慢,而原子钟的振荡频率极为稳定。两者拉开的差距累积到接近 1 秒时,国际地球自转服务(IERS)就会决定给 UTC 增加一个闰秒,通常安排在 6 月 30 日或 12 月 31 日的最后一秒。

2022 年,国际度量衡大会通过决议:最迟在 2035 年前取消闰秒机制,改用更平滑的方式处理天文时和原子时的差异。这意味着我们现在所处的时代,可能是最后一段「闰秒仍在发生」的时间。

如何在不同时区之间安排会议时间?

跨时区会议的核心目标,是找到所有与会者都在合理工作时间内的时间窗口。但现实是:当两地时差超过 8 小时,几乎不可能同时满足双方的工作时间

几条实用建议:

  • 优先选择两地都落在 9:00–18:00 之间的时段,这是双方工作状态最好的窗口
  • 如果时差超过 8 小时,可以轮流由一方适当调整(如提前或延后 1-2 小时),或改用异步沟通
  • 在日历邀请里标注每位参与者的当地时间,比只写一个时区更直观
  • 注意夏令时切换那几天,时差会比平时变化 1 小时

使用本站「双城时差计算」工具,可以看到两城 24 小时对应的完整列表,工具会自动标出黄金会议窗口。