UTC+8 · 东八区就是北京时间，UTC 时间怎么换算

看到 UTC+8、GMT+8、UTC 0、东八区不知道是什么？这一页把「偏移」讲透：首屏两只钟并排走秒，左边 UTC+8（北京时间）、右边 UTC，相差固定的 8 小时；中间能把 UTC 时刻换成北京时间，也能把「2026-10-01T06:00:00Z」这种 ISO 串整个粘进来解析；下面是 UTC−12 到 UTC+14 的完整偏移表，每行写着现在几点、与北京差几小时、代表城市。

怎么用

这一页解决的是一个很具体的困惑：看到 UTC+8、GMT+8、UTC 0、东八区这些写法，不知道它们到底是什么，也不知道怎么换成北京时间。从上到下四块，各管一件事。

一、先看首屏那两只钟

页面进来第一眼是并排的两只钟，都跟着秒走：

• 左边那只标着 UTC+8　北京时间，下面小字写着它的另外几个名字：GMT+8、东八区、中国标准时间 CST；
• 右边那只标着 UTC±0　世界协调时，小字写着 GMT、零时区，以及「ISO 串里那个 Z」。

两只钟的差永远是 8 小时，不会因为季节改变。钟下面常驻一行加粗的等式：UTC+8 ＝ GMT+8 ＝ 东八区 ＝ 北京时间（中国标准时间 CST）。如果你只是想确认一句话，看到这里就可以关掉页面了。

再下面一行小字跟着日期走：多数时候写「此刻两边是同一天」，但每天 UTC 的 16:00 一过，北京就跨进第二天了，那一行会改成「此刻北京已经是次日」。跨时区最容易错的不是几点，是哪一天，这一行专门防这个。

二、UTC ⇄ 北京时间换算（核心）

第二块是这一页真正的工具。它有两条路，结果落在同一张卡里。

第一条路：填日期时刻。先在「换算方向」下拉里选一个方向——「UTC → 北京时间（UTC+8）」或者「北京时间（UTC+8）→ UTC」，旁边的「对调」按钮一键互换。然后填日期和时刻（时刻框精确到秒），点「换算」。「填入现在」会按当前方向的来源时区把此刻填进去，适合先看一眼再改。

第二条路：把整串粘进来。下面那个长输入框认的是 ISO 8601 及其常见变体：

• 2026-10-01T06:00:00Z——结尾的 Z 就是 UTC+0；
• 2026-10-01T06:00:00+00:00——和上面那条完全等价；
• 2026-10-01 14:00:00+08:00——写的是北京时间，会被换回 UTC 再显示；
• 2026-10-01T09:30:00-05:00、2026-10-01T14:30+0800、2026-10-01 14:30+08——负偏移、紧凑写法、只写小时都行；
• 2026-10-01 06:00 UTC、2026-10-01 07:30 GMT+1——尾巴写名字的也认；
• 2026-10-01T06:00:00.123Z、2026-10-01T06:00Z——带毫秒、缺秒都行，毫秒会被略去；
• 2026/10/01 06:00、2026年10月1日 6点0分——斜杠日期和中文写法也认，全角数字会先转成半角；
• 2026-10-01——只有日期时按当天 00:00:00 算，页面会明说这一句。

串里没写时区后缀怎么办？按你当前选的换算方向的来源时区理解，并在结果下方写明「已经按 UTC±0 理解」或「已经按 UTC+8 理解」。解析成功后，上面那两个输入框也会被顺手填好，方便你接着微调。

下面三个示例按钮可以直接填进去试——它们指向的是同一刻，正好能演示「同一个时刻可以有好几种写法」。解析不了的时候会给一句能照着改的话：缺年月日就说缺年月日，日期不存在（比如 2 月 30 日）会单独指出来，偏移超出 UTC−12 到 UTC+14 的范围也会拦下来。

三、UTC−12 到 UTC+14 全表

第三块是一张按偏移排的完整表，四列：

• 偏移：UTC−12、UTC±0、UTC+5:30 这种写法，整小时的下面附一行中文编号（西五区、零时区、东八区）；
• 现在：这个偏移上此刻几点，跟着秒走；下面小字标「今天／明天／昨天」，基准是北京的日期；
• 与北京：写成「比北京慢 8 小时」这种人话，半小时档会显示成「比北京慢 2 小时 30 分」，不会被凑成整点；
• 代表城市：每档两三个。

UTC+8 那一行描了橙边，一眼能找到自己在哪儿。表里收全了现实中存在的非整点档：UTC+3:30（德黑兰）、UTC+4:30（喀布尔）、UTC+5:30（新德里、孟买）、UTC+5:45（加德满都）、UTC+6:30（仰光）、UTC+8:45（尤克拉）、UTC+9:30（阿德莱德冬季、达尔文）、UTC+10:30（阿德莱德夏季）、UTC+12:45（查塔姆冬季）。「复制表格」把整张表按制表符分隔复制走，贴进表格软件就是成列的。

表里城市后面括注的（冬）（夏）是制度事实：实行夏令时的地方一年里会在相邻的两行之间来回切。伦敦冬天在 UTC±0、夏天在 UTC+1；洛杉矶冬天在 UTC−8、夏天在 UTC−7；悉尼冬天在 UTC+10、夏天在 UTC+11。本页只按偏移排，不判断某座城市此刻处在哪一行——要按缩写认 EST 与 EDT 的区别，去时区缩写对照那一页；要按城市看某地此刻是不是在夏令时，去世界时钟那一页。

四、常识卡

最后四张卡回答四个最常被问到的问题：UTC 和 GMT 有什么区别、为什么中国全境只用一个时区、东八区都有哪些地方、UTC 偏移和「时区」为什么不是一回事。下面「怎么看结果」与「原理与冷知识」两段会把它们展开讲。

怎么看结果

结果卡里的六行

点完「换算」或「解析这一串」，结果卡最上面是一个大字读数——按你选的方向，给出北京时间或 UTC 的时刻，跨日时后面跟一个「（次日）」或「（前一日）」。下面六行把同一个时刻用几种坐标各写一遍：

• 你给的时刻：确认页面没把你的输入理解错，尤其是偏移后缀和日期；
• UTC±0：世界基准上的那一刻，跟同事转述、写进日历备注时用它最不会出错；
• UTC+8　北京时间：多数人真正要的那个答案；
• ISO 8601 写法：同一刻的两种标准串（带 Z 的和带 +08:00 的），可以直接抄进代码或接口参数；
• 你这台设备：人在国外时，这一行才是「我几点该打开电脑」；
• 跨不跨日：北京日期相对 UTC 日期差几天。

最后一行建议每次都扫一眼。UTC 的下午四点以后，北京就已经是第二天了——很多「怎么会差一天」的乌龙都出在这儿。

「偏移」这个数到底在说什么

一个偏移就是一句话：比世界基准快或慢多少。UTC+8 是快 8 小时，UTC−5 是慢 5 小时，UTC±0 是不快不慢。所以换算永远是一道加减法：

某地时刻 ＝ UTC 时刻 ＋ 该地偏移

本页所有换算都是这道纯算术，不依赖你设备的时区设置，也不依赖任何时区数据库。这也是为什么表里 UTC−12 那一行此刻显示的是北京的昨天——它比北京慢 20 小时，一天里有 20 个小时和北京不在同一个日期上。

半小时和 45 分钟的档别当成错的

很多人第一次看到 UTC+5:45 会以为是页面出了问题。它是真的：时区是国家定的，不是天文定的。印度全境统一用 UTC+5:30 取的是国土中部的折中，伊朗是 UTC+3:30，缅甸 UTC+6:30，澳大利亚中部 UTC+9:30，尼泊尔更特别，是 UTC+5:45。本页的时差一列按分钟显示，遇到这些档会写成「比北京慢 2 小时 15 分」，不会四舍五入成整点。

什么时候该怀疑读数

本页两只钟走的是你这台设备的时钟，偏移那一层是精确的，整体准不准取决于设备准不准。开着自动对时的设备通常在一秒以内。如果你发现两只钟和手机上的时间对不上，先检查设备时钟，别怀疑偏移——8 小时这个数是定义死的。想量一量自己的设备差多少，去本站的时间校准那一页。

另外有一种情况看起来像错：「你这台设备」那一行和「UTC+8」那一行对不上。这通常不是页面的问题，而是你的系统时区不在 UTC+8 上（人在国外，或者系统时区被设错了）。这一行读的是系统时区，和北京时间那一行本来就可以不同。

常见问题

格林尼治时间和 UTC 是一回事吗？

格林尼治标准时间（也写作格林威治时间，英文 Greenwich Mean Time，缩写 GMT）是以伦敦格林尼治天文台所在经线为基准的旧时标；UTC 是它的现代替代品。两者在日常使用中可以互换：格林尼治时间此刻几点，就看本页右边那只 UTC 的钟。要注意的是，伦敦本地的时间只在冬季等于 GMT，夏季会改用 BST（UTC+1），所以「格林尼治现在几点」和「伦敦现在几点」有半年是不一样的。

UTC 是什么时间？它和北京时间到底差多少？

UTC 是协调世界时（Coordinated Universal Time），全球统一的时间基准，不属于任何一个国家或城市。北京时间恒定比 UTC 快 8 小时，全年不变——因为中国大陆不实行夏令时。所以换算永远是加 8 或者减 8：UTC 的 00:00 是北京时间早上 8 点，UTC 的 12:00 是北京时间晚上 8 点，UTC 的 16:00 正好是北京时间的次日 0 点。

「东八区」和「UTC+8」是一回事吗？

日常语境里指同一个偏移，但严格说不完全等同。「东八区」是按经度划分的理论时区（东经 112.5 度到 127.5 度），而 UTC+8 是一个实际采用的偏移。中国全境横跨约 60 个经度却统一用 UTC+8，新疆、西藏在理论上并不属于东八区，却同样使用北京时间。所以技术文档里一律写 UTC+8 这种偏移写法，不用理论时区的编号。

UTC+8 和 UTC 8、GMT 8 是同一个东西吗？

是。中文搜索里常见「utc 8」「gmt 8」这种把加号漏掉的写法，指的都是 UTC+8。本页的解析框对「UTC+8」「UTC 8」「GMT+8」「+08:00」「+0800」「+08」都认，不会因为少写一个加号就解析不出来。真正需要注意的是负偏移别漏了减号——UTC−8 和 UTC+8 差整整 16 小时。

为什么我看到的 UTC 偏移会变？

因为那个地方实行夏令时。同一个时区一年里可能占两个偏移：伦敦冬天 UTC±0、夏天 UTC+1；纽约冬天 UTC−5、夏天 UTC−4。这正是「偏移」和「时区」的区别：偏移只是一个数，时区是一套带规则的完整定义。本页只排偏移，不判断某地此刻在哪一档；要看某地此刻是不是在夏令时、今年哪天调钟，用世界时钟那一页，它按时区库实时算。中国大陆在 1986 至 1991 年间实行过夏令时，之后取消，现在没有。

程序里存时间应该存什么？

结论很直白：存时间戳，或者存「UTC 时刻 + IANA 时区名」，别只存一个偏移数字。理由是偏移会变（夏令时），而且一个偏移对应很多时区，从偏移倒推不回具体地点。显示给用户的时候再按时区套一次偏移。要把时间戳和人看的时间互换，本站有时间戳转换那一页；想知道 Unix 时间戳是什么、各语言各数据库怎么取，去 Unix 时间戳那一页。

ISO 8601 里那个 T 和 Z 分别是什么？

T 是日期和时刻的分隔符，写成 2026-10-01T06:00:00；Z 是 UTC+0 的简写，读作 Zulu，来自无线电通话字母表。所以 2026-10-01T06:00:00Z 读作「二〇二六年十月一日 UTC 六点整」。标准也允许用空格代替 T（很多数据库导出就是空格），本页两种都认。带偏移的写法是 +08:00 这样的后缀，冒号可以省成 +0800。

手机上能用吗？

能。窄屏下两只钟改成上下排列，偏移表会收窄字号、必要时收掉「与北京」那一列（时差在换算结果里照样有），日期和时刻输入框各占一行，不需要横向拖动。

页面会不会把我填的时间传到服务器？

不会。这一页不发任何网络请求，两只钟和所有换算都在你的浏览器里用纯算术完成。写进本机存储的只有一个换算方向，输入框里的内容一个字符也不落盘。

原理与冷知识

UTC 这个缩写是吵出来的。英文全称是 Coordinated Universal Time，法文是 Temps Universel Coordonné，按各自的语序缩写应该是 CUT 和 TUC。国际组织最后各让一步，取了谁都不完全顺眼的 UTC，同时也保持了和 UT0、UT1 这一系列时标写法的一致。

GMT 和 UTC 的分野，本质是「谁来定义一秒」。GMT 的一秒是地球自转的一份，UTC 的一秒是铯原子跃迁的固定份数。地球自转并不匀速，所以两者会慢慢分开——为了把差距控制在一秒以内，1972 年起会不定期在某个月末插入一个「23:59:60」的闰秒，至今加过 27 次。它让无数系统出过事故，因为「一分钟有 61 秒」这件事几乎没人在代码里考虑过。2022 年国际计量大会决议计划在 2035 年前取消闰秒。

中国用一个时区，是一次明确的取舍。1949 年以前，中国曾划出中原、陇蜀、新藏等几个时区；此后全国统一采用东八区的北京时间。好处是全国的时刻表、通信、调度只有一套口径，铁路与航空的排班尤其受益；代价是新疆、西藏一带的作息与太阳时差得比较多——当地日常用「比内地晚两小时上班」这种方式自行错开，官方时刻仍然是北京时间。

UTC+8 上不止中国。同一个偏移上还坐着香港、澳门、台湾、新加坡、马来西亚、菲律宾、蒙古大部和澳大利亚西部。它们此刻的钟点完全一样，时区名字却各不相同。最有意思的是新加坡：它历史上曾用过 UTC+7:30，1982 年才改到 UTC+8，理由之一就是与马来西亚和周边的商业时间对齐。

UTC+14 是人为造出来的「最早」。基里巴斯的莱恩群岛在 1995 年把国际日期变更线东移，让全国日期统一，顺带把自己变成了地球上最早迎来新一天的地方。它的偏移 UTC+14 意味着：那里的时刻比 UTC−12 上的贝克岛整整早 26 小时——同一瞬间，地球上会同时存在三个不同的日期。

45 分钟的时区是有讲究的。UTC+5:45 是现存最有名的 45 分钟档，尼泊尔以境内一座山峰所在的经度作为标准，算出来正好落在这个刻度上，顺带也把自己和邻国印度的 UTC+5:30 区分开。另一个 45 分钟的例子是澳大利亚的尤克拉（UTC+8:45），常住人口只有几十人，却在偏移表里稳稳占一格；新西兰的查塔姆群岛则是 UTC+12:45。

有过比半小时更细的偏移。荷兰在 1909 到 1937 年间用过精确到秒的国家标准时（UTC+0:19:32.13），利比里亚直到 1972 年还在用 UTC−0:44:30。时区数据库把这些都留着，因为它不只回答「现在几点」，还要回答「1950 年的那天当地几点」——这也是一个正经时区库体积不小的原因。

偏移不是时区，这个误会在代码里代价最高。把用户的「时区」存成一个整数偏移，是很多系统在夏令时那两个周末集体出错的根源：同一个 UTC−5 冬天是纽约、夏天是芝加哥，从数字倒推不回地点。正规的日历邀请（.ics 文件）里写的是 TZID:America/New_York 而不是偏移，就是为了躲开这件事。专业工具存地点，显示时才算偏移，顺序不能反。