WORLD TIME 全球时间 · 时区 · 时差

世界时间,此刻尽在眼前

从北京到纽约,从伦敦到悉尼,同一刻在地球上呈现出不同的钟表读数。下面这块看板把常用城市放在一起:搜索、添加、收藏,时区偏移与夏令时由浏览器按 IANA 规则实时计算,不需要刷新页面。

浏览器本地计算 夏令时自动处理 收藏保存在本机

THE WORLD RIGHT NOW

同一刻,十二座城市的不同一天

时差不是抽象数字。它决定纽约的会议邀请落在北京的深夜,也决定悉尼的周一早晨比洛杉矶早了大半个地球。下表按实时状态更新,日期与“比北京快/慢”的提示会随时区规则变化。

常用城市此刻时间,按 UTC 偏移大致从西到东排列
城市当地日期当地时间与北京时区说明
洛杉矶LOS ANGELES------美国 · 北美洲
纽约NEW YORK------美国 · 北美洲
圣保罗SAO PAULO------巴西 · 南美洲
伦敦LONDON------英国 · 欧洲
UTCCOORDINATED UNIVERSAL TIME----:--:----协调世界时 · 全球基准
巴黎PARIS------法国 · 欧洲
莫斯科MOSCOW------俄罗斯 · 欧洲
迪拜DUBAI------阿联酋 · 亚洲
新德里NEW DELHI------印度 · 亚洲
新加坡SINGAPORE------新加坡 · 亚洲
东京TOKYO------日本 · 亚洲
悉尼SYDNEY------澳大利亚 · 大洋洲

表中时间为浏览器此刻计算的结果,跨日情况会在日期列直接体现。

查看完整世界时间表

BY COUNTRY / 按国家

先选国家,再看城市

同一个国家不一定只有一条时间线。美国本土横跨四个时区,澳大利亚的中部使用半小时偏移,加拿大最东端的纽芬兰比大西洋时间再晚半小时。国家页会把它们一次讲清。

另有北京时间与 UTC 的独立说明页,适合先建立基准概念。

浏览全部国家与基准时间

UNDERSTANDING WORLD TIME

世界时间不是一张静态的表

如果时区只是把地球切成 24 份,事情会简单得多。真实情况是:经度提供基础,行政边界做出调整,夏令时再叠加一层季节性变化。理解这三层,很多“时间对不上”的问题会自己消失。

时区是行政决定,不只是经度

地球每小时转过 15 个经度,因此理论上每隔 15 度可以设一个时区。但国家会根据贸易伙伴、交通网络与行政管理调整边界。西班牙的经度接近英国,却使用中欧时间;中国横跨五个理论时区,全国统一使用北京时间。你在地图上看到的时区线,往往是谈判与治理的结果。

这也是为什么不能按经度“估算”某座城市的时间。乌鲁木齐的官方钟表与北京一致,尽管两地的太阳时差接近两小时;印度使用 UTC+5:30,也不是任何整点经线能解释的。查城市时间,最终要落到 IANA 时区名称上。

UTC 是坐标,城市时间是投影

协调世界时 UTC 不隶属于任何城市,它是全球时间的共同坐标。北京时间是 UTC+8,纽约冬令时是 UTC−5,伦敦冬令时是 UTC+0。把城市时间写成“UTC 加偏移”,就像给每个钟表标注它在坐标系里的位置,跨系统传输时不容易出错。

本站的换算逻辑也是如此:先把输入的钟表时间还原成一个绝对时间点,再投影到目标城市。这样即使跨越夏令时切换、国际日期变更线或半小时时区,结果仍然一致。

夏令时让时差一年变两次

美国、加拿大、英国、欧盟、澳大利亚部分地区与新西兰实行夏令时,北半球通常在三月调快、十月或十一月调回,南半球则相反。北京全年不调表,所以北京与纽约的时差会在 12 与 13 小时之间切换,与伦敦在 7 与 8 小时之间切换。看到旧文章里的时差数字,先确认它写于哪个季节。

日期差比小时差更隐蔽

跨过国际日期变更线,或者只是跨过午夜,日期就会变化。北京周一上午十点,檀香山还是周日下午四点;北京晚上十一点,伦敦还是周一下午三点。安排会议、航班与截止日期时,只盯小时数很容易把日期写错。本站的每个时钟与换算结果都会同时显示日期与星期。

WORKING ACROSS ZONES

跨时区协作,按顺序做四件事

把时区问题当成一道算术题,往往会漏掉日期与夏令时。更稳的做法是固定一套流程:先锚定时间点,再找重叠窗口,最后检查季节规则。

先写 UTC 锚点,再写各地时间

会议记录里先写“UTC 2026-11-10 08:00”,再列出北京 16:00、伦敦 08:00、纽约 03:00。只要锚点不变,任何人重新换算都能得到同一结果。

找出双方都在工作时间的交集

用 24 小时重叠图看两个城市的可用窗口。北京与伦敦的交集在下午到晚间,北京与纽约则集中在晚上。交集越短,会议越应该控制时长与目标。

检查日期附近的夏令时切换

切换周前后的时差可能与平时不同。邀约里写清城市、日期、时间与 UTC 偏移,比只写“周二上午”可靠得多。

为无法重叠的部分留异步空间

不是所有事情都需要同步会议。把背景材料提前写成文档,用评论收集意见,再开一个 20 分钟的短会解决分歧,往往比迁就所有人更有效。

WHY THIS SITE

一块看板背后的四件事

世界时间工具很多,差别往往在细节:时间是否真的在走、夏令时怎么处理、城市够不够全、中文说明是否读得懂。这里把四件事都放进同一套页面里。

01 / LIVE

不是截图,是正在走的时间

所有钟表每秒刷新,日期、星期、跨日提示与夏令时状态一起更新,不需要手动刷新页面。

02 / LOCAL

计算留在浏览器里

不请求第三方时间接口,不上传你选择的城市。断网后重新打开,已缓存的页面仍能显示时间。

03 / IANA

按真实时区规则换算

使用 IANA 时区数据库,自动处理 178 个城市的夏令时、半小时偏移与历史规则。

04 / READING

为中文阅读而写

每个国家与城市都有独立说明,解释时差、夏令时与沟通窗口,而不只是一张冷冰冰的表。

TIME NOTES / 时间笔记

把时间问题写成可复用的方法

时区、夏令时、日期变更线与时间格式,背后都有清楚的规则。时间笔记不做新闻搬运,只把这些问题拆开讲透,方便你在下一次排期时直接使用。

共 6 篇笔记,持续补充与时间换算相关的实用主题。

浏览全部时间笔记

FAQ / 常见问题

开始之前,先解决几个疑问

关于准确性、夏令时、收藏与隐私,这里有最短的回答。更完整的问题集中在常见问题页。

查看全部常见问题
世界时间显示的时间准确吗?01

页面读取你设备上的系统时钟,再按 IANA 时区数据库的规则换算成各城市当地时间。只要设备时间准确,显示结果就是准确的;夏令时、半小时偏移和跨日也会一并处理。本站不依赖外部时间接口,因此不会因为接口故障而停摆。

为什么有些城市的时间差不是整数小时?02

时区并不总是按整小时划分。印度是 UTC+5:30,尼泊尔是 UTC+5:45,澳大利亚南澳是 UTC+9:30,加拿大纽芬兰是 UTC−3:30。与这些地区约时间时,整点往往对应对方的半点或三刻,最好直接写出两地的具体时间。

夏令时会影响这里的时差吗?03

会。美国、加拿大、英国、欧盟、澳大利亚部分地区和新西兰等地实行夏令时,切换后时差会变化一小时。本站按查询当天的真实偏移计算,所以同一个城市对在不同月份可能显示不同的小时差。

北京时间和 UTC 是什么关系?04

北京时间固定为 UTC+8,不实行夏令时。UTC 12:00 对应北京时间 20:00,UTC 00:00 对应北京时间 08:00。北京时间并不是北京的地方平太阳时,后者比官方时间慢约 14 分钟。

我可以收藏自己常看的城市吗?05

可以。在首页或世界时钟页搜索并添加城市后,选择会保存在当前浏览器的本地存储中,下次打开仍在。清除浏览器数据或更换设备后需要重新添加。

需要注册或付费吗?06

不需要。所有工具都可以直接使用,没有登录、订阅或次数限制。页面只加载访问统计脚本,用于了解整体访问情况,不读取你输入的时间或选择的城市。

READY WHEN YOU ARE

把下一场跨时区会议,
安排在双方都清醒的时候

选择两个城市,查看 24 小时重叠与推荐时段;或者把已经定好的时间换算成所有参与城市当地时间。