世界时间 · 世界时钟与时差换算

一面同屏走秒的时钟墙：北京、纽约、洛杉矶、伦敦、柏林、东京、悉尼和 UTC，每张卡带当地日期星期、与北京的时差、白天黑夜和夏令时标记，搜城市即可加。下面还有三件事：任意两地的时刻互换（跨日标次日／前一日）、24 行两地对照表、2～5 个城市的会议时段分色带，点一列就能复制「北京 周四 21:00 ＝ 纽约 周四 09:00」。另附 UTC、ISO 8601 与 Unix 时间戳。

怎么用

这一页只做一件事：把「那边现在几点、差几个小时、约个两边都方便的时间」一次说清楚。从上到下五块，各管一件事。常说的时区转换、时差换算，都在这一页。

一、我的时钟墙

打开就是一面卡片墙，默认挂着北京、纽约、洛杉矶、伦敦、柏林、东京、悉尼和 UTC 八个。每张卡上有五样东西：

• 当地时间，走到秒，所有卡片同时跳；
• 当地的日期与星期；
• 与北京的时差，写成「比北京慢 13 小时」，后面跟着 UTC 偏移（如 UTC−5）；
• 白天黑夜的小图标，按当地 6 点到 18 点粗分，不必看数字就知道那边是不是还在睡；
• 「昨天／今天／明天」标，以北京的日期为基准——这是跨时区最容易错的地方。

正在实行夏令时的城市，卡片下面会多一行「正在实行夏令时」。

加城市用上面的搜索框，中文名、国家、别称、IANA 时区名都能搜：输「纽约」「德国」「美东」「太平洋时间」「CEST」「格林尼治」「Tokyo」「Asia/Shanghai」都能命中，甚至直接输「美国现在几点」也搜得到。点搜索结果里的按钮就加进来。每张卡下面有「上移」「下移」「移除」三个小按钮，把最常看的那几个排到前面。墙上最多挂 12 个，选择只存在这台设备上。

二、时区换算：跨日会标出来

第二块是核心。选从哪个城市、到哪个城市，填一个日期和当地时刻，下面立刻给出对方的当地日期时刻。三个按钮：

• 「现在」：把日期时刻一键填成出发地此刻的当地时间；
• 「对调」：两端互换，省得重选；
• 「复制结果」：把「北京 2026 年 9 月 17 日 21:00 ＝ 纽约 2026 年 9 月 17 日 09:00」这一整句复制走。

结果卡里除了两边的完整日期时刻，还给出两地时差、跨不跨日（标成「次日」或「前一日」）以及这一刻对应的 UTC 时间。跨日那一行值得专门看一眼：北京周五上午的会，落到纽约往往还是周四晚上，发邮件时写错一天比写错一小时更麻烦。

三、两地对照表

承接「美国时间与北京时间对照表」这类需求：选两个城市，出一张 24 行的整点对照表——左边那地的 0 点到 23 点，右边对应几点、是不是跨了日。当前这一小时会高亮，所以一眼能定位「现在在表的哪一行」。表上方那句话直接告诉你结论，比如「现在纽约比北京慢 12 小时（夏令时期间）」。

表格可以整张复制，复制出来是制表符分隔的纯文本，贴进表格软件或聊天窗口都能用。

四、会议排期

跨国开会最难的不是换算，是挑一个大家都不难受的时刻。勾选 2～5 个城市（从你的时钟墙里勾），选一天，页面画出一条 24 小时的横向刻度带，一个城市一行：

• 绿色＝当地 9 点到 18 点，上班时间；
• 黄色＝当地 7～9 点和 18～22 点，勉强能约；
• 灰色＝其余时段，那边多半在睡觉。

刻度按第一个城市的整点排列。页面会自动帮你挑一列各地加起来最舒服的，你也可以点刻度行上的任意一列换一个。选中之后下面列出各城市在那一刻的当地日期时刻，「复制这一刻」给出一句可以直接发出去的话：「北京 周四 21:00 ＝ 纽约 周四 09:00 ＝ 伦敦 周四 14:00」。

五、UTC 与时间戳

最后一小块给开发和运维用：当前 UTC 时间、ISO 8601 写法（如 2026-09-17T13:05:09Z）、Unix 时间戳的秒与毫秒，每行一个「复制」。写日志、对接接口、排查「服务器时间怎么差 8 小时」时，直接抄走比自己心算靠谱。

六、这一页不做的事

本页的时间以你这台设备的时钟为准，页面本身不向任何服务器要时间。怀疑自己设备的时间不准，去时间校准量一下偏差；想要一块满屏大字的北京时间投到大屏幕上，去北京时间全屏显示；要算两个日期相差多少天、往后推多少天，去日期计算器；要数着某个日子还剩多少天，去倒数日。本页也不做农历、黄历和节气。

怎么看结果

时差不是一个固定数字

搜索里常见「中美时差 12 小时」「美国时差 13 小时」两种说法，两个都对，也都不完整——因为夏令时。纽约在夏令时期间是 UTC−4，其余时间是 UTC−5，与北京的差就在 12 和 13 之间跳；洛杉矶在 15 和 16 之间跳。一年里有大约七个月是「短的那个数」，四个多月是「长的那个数」，还有两天是换季日本身。

所以这一页不给你背一个数字，而是每次都实时算：卡片上的「比北京慢 12 小时」是此刻的真实差值，旁边会标出那边是不是正在夏令时。要提前算某一天的，用第二块的换算，把日期填成那一天——换季之后的日期会自动用新的偏移。

「昨天／今天／明天」那个小标

跨时区最常见的错不是几点，是哪一天。北京与美西差十五六个小时，两地有大半天日期是对不上的：北京周一上午 9 点，洛杉矶还是周日下午 6 点。时钟墙上每张卡右上角的标就是干这个的，基准是北京的日期：写「昨天」表示那边还停在北京的昨天，写「明天」表示那边已经进入北京的明天（奥克兰、悉尼常见）。

换算结果里的「次日／前一日」是另一个基准：以你填的那个出发地日期为准。

夏令时标记

卡片和结果里的「夏令时」不是按月份猜的，而是实打实算出来的：页面拿当年一月和七月各探一次那个时区的偏移，取小的那个当作标准时，当前偏移比它大就是正在夏令时。这个做法对南北半球同样成立——悉尼、奥克兰的夏令时在北半球的冬天，靠月份猜必错。

换季那两天的两件怪事

一年里有两天，当地的「墙上时间」会出问题，本页都老实标出来：

• 春天拨快的那天，有一小时不存在。美国多数地区当地 2:00 直接跳到 3:00，所以「2 点 30 分」这个时刻那天压根没有。你要是在换算里填了这么一个时刻，页面会提示「你填的这个当地时刻并不存在，结果按拨快之后的时刻算」。
• 秋天拨回的那天，有一小时出现两次。当地 2:00 拨回 1:00，于是「1 点 30 分」当天来了两遍。页面会提示这一点，并按第一次（夏令时那一次）给结果。

很多网页时钟遇到这两天会静默给出一个错一小时的答案，本页选择说出来。

会议带的颜色是怎么定的

绿黄灰三档是一个通用取舍，不是什么标准：9～18 点算上班时间，7～9 与 18～22 算「能约但要占用私人时间」，其余算睡觉时间。它的价值在于把三四个城市的作息叠在一张图上——你会很直观地发现，北京与美西几乎没有共同的绿色区间，能选的最好结果通常是一边早上 7 点、一边晚上 10 点这样的黄配黄；而北京与欧洲则有一段稳稳的绿配绿（北京下午对欧洲上午）。

半小时和 45 分钟时区

页面按分钟算时差，所以印度（UTC+5:30）、尼泊尔（UTC+5:45）、伊朗（UTC+3:30）、缅甸（UTC+6:30）、澳大利亚中部（UTC+9:30）这些地方会显示成「比北京慢 2 小时 30 分」这样的写法。和这些地方约时间时，整点约常常在对方那里落成半点，提前看一眼对照表能省掉一次误会。

时区算不出来的时候

极老的浏览器或被裁剪过的运行环境可能没有完整的时区库，这时页面顶部会出现一条提示，各城市退回「固定偏移、不含夏令时」的估算，卡片上也会注明。这种情况下换季前后可能差一小时，结论仅供参考。

常见问题

「世界时间」「世界时钟」「世界标准时间」是一回事吗？

日常说的「世界时间」多数时候指的就是各地当地时间的总览，也就是这一页上半部分做的事——想做世界时间查询、要一张实时走秒的世界时间表，看时钟墙就够，搜城市还能往上加；「世界标准时间」通常指 UTC，即所有时区的基准。还有一个容易混的词是 GMT——严格说 GMT 是按地球自转定义的旧时标，UTC 是按原子钟定义的现行标准，两者相差不到一秒，日常当同一个用没问题，写技术文档时应该用 UTC。

页面上的时间准吗？以谁为准？

页面显示的每一个地方的时间，都是拿你设备的当前时刻加上那个时区的偏移算出来的。也就是说，时区换算这一层是精确的（夏令时、半小时时区都算对），但整体准不准，取决于你设备的时钟准不准。开着自动对时的设备通常在一秒以内；要确认可以去时间校准量一下偏差。

为什么时区名写成「Asia/Shanghai」而不是「中国」？

这是 IANA 时区数据库的命名规矩：用「大区／代表城市」而不是国家名。原因很实际——国家会改名、会分裂合并，一个国家也可能有多个时区，而一座具体的城市相对稳定。所以中国大陆用 Asia/Shanghai（不是 Asia/Beijing，这是历史选择的结果）、美东用 America/New_York、印度用 Asia/Kolkata。本页的搜索框认这些名字，你直接粘贴 Asia/Tokyo 也能搜到。

能显示某个国家全部城市吗？

不能，也不必要。绝大多数国家全境只有一个时区，收一座代表城市就够了；只有美国、加拿大、澳大利亚、俄罗斯、巴西这类横跨多时区的国家才需要多收几座。页面收了七十来座城市，覆盖各大洲、含半小时与 45 分钟时区。搜不到某个城市时，找一个和它同一个时区的大城市即可，时刻完全一样。

会议排期能不能考虑周末和节假日？

目前只按一天里的钟点分色，不判周末，也不内置任何国家的法定节假日——各国的假期年年由官方另行公布，做不准不如不做。刻度带上给出了当地的星期，遇到周六周日你自己就能看见。要按工作日算天数，用本站的工作日计算器。

手机上能用吗？

能。窄屏下时钟墙会自动变成两列，会议排期的色带可以左右滑动，其余部分整体收窄。手机上的日期和时刻用的是系统自带的选择器。

时间戳那一栏的秒和毫秒有什么区别？

Unix 时间戳是「从 1970 年 1 月 1 日世界协调时零点到现在经过了多少秒」。很多后端、数据库用秒，JavaScript 和不少接口用毫秒，两者相差一千倍——排查「时间显示成 1970 年」或者「日期跑到五万年后」的问题时，十有八九就是这两个搞混了。页面两个都给，各带复制。

原理与冷知识

时区数据是一份全球共同维护的文件。浏览器、手机、服务器里那份时区规则叫 IANA 时区数据库（也叫 tz database），记录了从 1970 年至今每个地区的偏移变化、夏令时规则和历史调整。它每年发布好几个版本，因为总有国家在改：某国宣布不再实行夏令时、某地区整体挪半小时、某个国家换了标准时。这也是网页不应该自己写夏令时日期表的根本原因——写死的那一刻就开始过期，本页把这件事完全交给这份数据库。

时区是铁路逼出来的。在十九世纪中叶以前，每座城市用自己的太阳时，隔壁城镇差几分钟没人在意。铁路来了之后，时刻表成了灾难：同一列车在沿途每一站都要换算当地时间。1883 年北美铁路公司率先统一划分时区，次年的国际子午线会议确定以格林尼治为本初子午线。也就是说，我们今天用的时间体系，是为了让火车不撞车而发明的。

夏令时的账不好算。它最初的理由是省照明电，今天的研究普遍认为这点节约非常有限，反而带来切换前后的作息紊乱、交通事故与软件故障。欧盟在 2019 年投票通过取消季节性时间调整，但因为成员国无法就「全年用冬令时还是夏令时」达成一致而搁置至今。换句话说，它的存废更多是政治协调问题，不是技术问题。

有的地方的时差是「半小时」，还有过 45 分钟的。尼泊尔的 UTC+5:45 是现存最有名的 45 分钟时区。它不是随便定的：尼泊尔以境内的马查布查雷峰所在经度作为标准，正好落在这个刻度上，并且带着「我们不是印度的一部分」的意味。类似地，印度的 +5:30 覆盖了整个国土，导致东北部的天亮时间比西部早将近两小时，当地长期有「要不要单独设一个时区」的讨论。

国际日期变更线是弯的，而且被改过。它大体沿 180 度经线，但为了不把一个国家劈成两天，一路拐来拐去。萨摩亚在 2011 年为了和澳大利亚、新西兰做生意方便，直接跳过了 12 月 30 日——那一年那个国家没有 12 月 30 日这一天。基里巴斯在 1995 年把变更线东移，让全国日期统一，顺带成为世界上最早迎来新一天的国家。

为什么各地时间要以 UTC 为轴。如果每个地方各记各的，跨时区的先后关系就没法判断。现在的通行做法是：系统内部一律存 UTC 或 Unix 时间戳，只在显示给人看的那一刻才套上时区。这一页也是这么算的——先把你填的当地时刻反解成 UTC，再折算到目标城市。反解这一步比正向难：因为存在「不存在的一小时」和「出现两次的一小时」，所以要先按标准偏移猜一次，用时区库校正，再验一遍墙上时刻对不对。

闰秒即将退场。地球自转并不匀速，为了让 UTC 与天文时不至于差太远，1972 年起会不定期在某个月末插入一个「23:59:60」的闰秒，至今加过 27 次。它让无数系统出过事故——因为「一分钟有 61 秒」这件事几乎没人在代码里考虑过。2022 年国际计量大会决议计划在 2035 年前取消闰秒。有意思的是近些年地球自转反而在变快，如果趋势延续，人类可能会第一次面对「负闰秒」，也就是把某一分钟减掉一秒，那会比正闰秒更难对付。

中国一个时区，横跨约 60 个经度。理论上够分五个时区，历史上也确实分过（中原、陇蜀、新藏等）。1949 年后统一为北京时间，好处是全国的时刻表、通讯、调度不再需要换算，代价是西部作息与太阳错位——所以才有了「新疆时间」这种生活上的说法：法定时间仍是北京时间，上班时间整体往后挪两小时。顺带一提，北京时间对应的基准经度是东经 120 度，那条线其实经过杭州一带，北京本身的地方太阳时比北京时间还慢十几分钟。

还有比整点更奇怪的时区历史。荷兰在 1909 到 1937 年间用过 UTC+0:19:32.13 这样精确到秒的国家标准时；利比里亚直到 1972 年还在用 UTC−0:44:30。时区数据库里保留着这些记录，这也是为什么一个正经的时区库体积不小——它不只回答「现在几点」，还要回答「1950 年的那天当地几点」。