时区缩写对照 · UTC、GMT、EST、PST、CST 是什么时间

邮件和公告里写着「8 PM EST」「10:00 PT」「UTC+8」，到底是北京时间几点？这一页按缩写查：43 条常用时区缩写一张表，每行直接写着它现在几点、比北京快慢多少；把整串时间粘进输入框就能换成北京时间；还有 UTC 偏移互换、从 UTC−12 到 UTC+14 的文字版刻度带，以及 CST、IST、BST 这几个一名两义的缩写该怎么分辨。

怎么用

这一页解决的是一个很具体的麻烦：邮件、会议邀请、游戏公告、直播预告里写着一串带缩写的时间，你不知道换成北京时间是几点。从上到下六块，各管一件事。

一、先看那张「撞缩写」提示卡

页面最上面是一张橙色的提示卡，列着三个最容易坑人的缩写：

• CST＝中国标准时间（UTC+8），也＝美国中部标准时间（UTC−6），还有一个古巴标准时间（UTC−5）。前两个差整整 14 小时，认错了整件事都会错；
• IST＝印度标准时间（UTC+5:30），也可能是爱尔兰夏令时或以色列标准时间；
• BST＝英国夏令时（UTC+1），也可能是孟加拉标准时间（UTC+6）。

卡片上加粗的那一条，是本页表里收录的那个义项。结论写在卡片最下面：看到有歧义的缩写，以发件方所在地判断；拿不准就直接问对方要 UTC 偏移。这一句不是客套话——跨国协作里写「UTC+8 09:00」比写「CST 09:00」能省掉一轮来回。

二、缩写速查表

主表收了 43 条常用缩写，每一行六样东西：缩写、中文名（下面小字是英文全称）、UTC 偏移、它现在几点（跟着秒走）、比北京快慢多少、代表城市。夏令时那一档的缩写（EDT、PDT、CEST、BST 这类）行底色是浅黄的，缩写后面还有一个「夏令」小标。

上面的搜索框认四种东西：缩写（输 pst、est）、中文名（输「东部」「中国标准时间」）、代表城市（输「洛杉矶」「新德里」），以及偏移本身（输 UTC+8）。搜完点「看全部 43 条」回到完整的表。右边的「复制表格」把整张表按制表符分隔复制走，贴进表格软件就是成列的，「现在」那一列填的是你点复制那一刻的时间。

三、ET／CT／MT／PT 这四个统称

表下面单列了一张小卡，因为这四个和别的不一样：它们本身没有固定偏移。ET 冬天等于 EST（UTC−5）、夏天等于 EDT（UTC−4），CT、MT、PT 同理。所以这四张卡上写的是「现在＝EDT　UTC−4」这样的实时结论，底下跟着当地此刻的时刻。

这个判断交给你浏览器自带的时区库做，页面本身不写任何换季日期——各地的夏令时规则会被立法改动，写死的那一刻就开始过期。极老的浏览器如果拿不到时区库，这一块会退回各自的标准时并在上方给出红字说明，冬天看是对的、夏天会差一小时。

四、把「8 PM EST」换成北京时间（核心）

这是全页最该用的一块：把那串时间整个粘进输入框，点「换算」。认得的写法包括：

• 8 PM EST、8:30PM EST——12 小时制，AM／PM 大小写都行；
• 10:00 PT——统称缩写，会自动判断此刻是标准时还是夏令时；
• 2026-10-01 14:30 PST——带日期，也支持 2026/10/01 和「10 月 1 日」这种写法；
• UTC+8 09:00、GMT-7 21:00、UTC 8 09:00——直接写偏移；
• 2026-10-01T14:30Z——ISO 8601 里那个 Z 就是 UTC；
• JST 晚上8点半——中文的「上午／下午／点／半」也认。

日期可以省，省了就按那个时区的今天算——注意不是按北京的今天，因为两边日期常常对不上。结果卡里给五行：你填的时刻、换算出的北京时间、同一刻的 UTC、你这台设备上的时刻，以及时差与跨日标记。跨日会明写「次日」或「前一日」。

粘进来的是 CST 09:00 这种一名两义的缩写时，页面不会替你猜，而是出两个按钮让你选「按中国标准时间算」还是「按美国中部标准时间算」。下面三个示例按钮可以直接填进去试。解析不了的时候会给一句人话，告诉你缺的是时区还是时刻。

五、UTC 偏移换算

两个下拉各选一个偏移，填日期和时刻，立刻给出对方几点。偏移候选从 UTC−12 排到 UTC+14，并且把现实中存在的半小时与 45 分钟档都收了（UTC+3:30、UTC+4:30、UTC+5:30、UTC+5:45、UTC+6:30、UTC+9:30、UTC+10:30、UTC+12:45 等）。「填入现在」按左边那个偏移的此刻填表，「对调」把两边互换，「复制结果」把整句复制走。UTC+8 那一项后面直接标着「北京时间」。

这两个下拉的选择会记在你这台设备上，下次打开还是它；你在输入框里填的时间不会被保存。

六、时区刻度带与常识卡

最后两块是给「时区图」这类需求准备的。刻度带从 UTC−12 到 UTC+14 一格一小时，每格写着这个偏移上的代表城市和那边现在几点，UTC+8 那一格描了橙边。电脑上横向排、可以左右滑，手机上自动改成纵向一列，不用横向拖。常识卡六条，讲清楚时区为什么是一小时一格、半小时时区是怎么来的、DST 是什么、GMT 与 UTC 的区别、国际日期变更线，以及最要紧的一条：缩写从来不是标准，偏移才是。

怎么看结果

缩写的偏移是定义，不随季节变

这是最容易绕晕的一点，值得单独说清楚：EST 永远是 UTC−5，EDT 永远是 UTC−4，它们各自的偏移是定义死的，不会因为季节改变。随季节变的是「纽约现在用哪个缩写」——冬天用 EST、夏天用 EDT。

所以本页的表可以把偏移写死，而 ET／CT／MT／PT 那张小表必须实时算。反过来说，如果你在七月收到一封写着「EST」的邮件，两种可能：对方确实想说 UTC−5（少见），或者对方只是习惯性地写了 EST 其实指的是当下生效的 EDT（常见）。差一小时的会议就是这么错过的——这种时候最好回一句确认。

「现在」那一列和「与北京」那一列

「现在」是拿你设备的当前时刻加上该缩写的偏移算的，同一秒里整张表一起跳。下面那行小字标着「今天／明天／昨天」，基准是北京的日期：写「昨天」表示那个偏移上现在还停在北京的昨天。跨时区最常出错的不是几点，是哪一天，这一行就是专门防这个的。

「与北京」那一列写成「比北京慢 13 小时」这种人话，半小时时区会显示成「比北京慢 2 小时 30 分」，不会被凑成整点。

解析结果里的四行时间

结果卡把同一个时刻用四种坐标各写了一遍，各有用处：

• 你填的时刻：确认页面没有把你的输入理解错，尤其是 AM／PM 和日期；
• 北京时间：多数人真正要的那个答案；
• 同一刻的 UTC：跟同事转述、写进日历备注时用它最不会出错；
• 你这台设备：人在国外时，这一行才是「我几点该打开电脑」。

最后一行的跨日标记建议每次都扫一眼。美东晚上的活动，落到北京基本都是次日上午；反过来，新西兰夏令时的凌晨换成北京时间会退到前一日。

AM／PM 的两个边界

这两个是日常最容易写反的：12 AM 是半夜 0 点，12 PM 是中午 12 点。很多人凭直觉会把 12 PM 当成午夜。页面按这个标准解析，并且当你写出「13 PM」这种不存在的组合时会直接拦下来，告诉你带 AM／PM 时钟点只能是 1 到 12。

为了少一点歧义，写给别人看的时候建议直接用 24 小时制，或者写成「12:00 noon」「12:00 midnight」。

解析不了的时候

输入框认不出来时会给一句具体的话，而不是笼统的「格式错误」：缺时区就说缺时区，缺时刻就说缺时刻，日期不存在（比如 2 月 30 日）会单独指出来。三个示例按钮是最快的自查方式——点一个看它怎么被解析，再照着改你手里那一串。

常见问题

GMT 和 UTC 到底有什么区别？

GMT（格林尼治平时）按地球自转定义，历史更久，日常和法律文本里仍在用——英国的冬季时间在法律上就叫 GMT。UTC（协调世界时）由全球几百台原子钟加权得出，是现行的国际标准。两者相差不到一秒，日常交流当同一个用没问题，但写接口文档、日志格式、合同条款时应当写 UTC。本页表里 UTC 和 GMT 各占一行，偏移都是 0。

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

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

夏令时（DST）是什么？中国有夏令时吗？

DST 是 Daylight Saving Time，夏天把钟往前拨一小时，让傍晚的天光更长。制度上的通行规则是：北美多数地区从三月的第二个周日到十一月的第一个周日，欧盟从三月的最后一个周日到十月的最后一个周日，南半球的澳大利亚东部与新西兰则相反，在当地春天开始——这些规则会被各地立法改动，具体某一年某一天以当地官方公布为准，本页不写死任何日期。中国大陆在 1986 至 1991 年间实行过夏令时，之后取消，现在没有。

为什么同一个缩写会有两个意思？就没人管吗？

因为时区缩写从来没有一份全球统一的注册表。它们是各国各行业自己叫出来的习惯写法，撞车再正常不过：CST 至少三个意思，IST 至少三个，BST 两个，AST 在北美指大西洋标准时、在中东则被用来指阿拉伯标准时。真正没有歧义的写法只有两种：UTC 偏移（UTC+8）和 IANA 时区名（Asia/Shanghai）。程序里存时间一律用 UTC 或时间戳，显示时才套时区，就是为了躲开这堆缩写。

这一页和世界时钟、时间戳转换怎么分工？

三页的入口不同：这一页按缩写查，手里有一串「8 PM EST」就用它；世界时钟按城市查，要同屏看好几个地方的时刻、排跨国会议用它；时间戳转换管的是 1789999999 这种 10 位、13 位数字和人看的时间之间的互换，写代码排日志用它。要按国家或地区深看，本站另有美国时间和欧洲时间两页。

手机上能用吗？

能。窄屏下缩写表会自动收掉英文全称和代表城市两列，只留缩写、中文名、偏移、现在这几样；时区刻度带改成纵向一列，不需要左右拖；输入框和下拉整体占满一行。

能查某个具体城市用哪个缩写吗？

表里每一行都写了代表城市，搜索框直接输城市名就能反查——输「洛杉矶」会同时命中 PST 和 PDT 两行，输「新德里」命中 IST。要更完整的城市列表、要看那座城市此刻是不是在夏令时，用世界时钟那一页，它按 IANA 时区库实时判断。

页面会保存我填的内容吗？

不会。输入框里的时间只活在页面内存里，关掉就没了；写进本机存储的只有偏移换算那两个下拉的选择。这一页也不向任何服务器发请求，所有查表和换算都在你的浏览器里完成。

原理与冷知识

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

缩写是各叫各的，偏移才是共识。IANA 时区数据库里其实保留了大量历史缩写，但它明确说明这些缩写不构成标准，只是显示用的字符串。真正被软件依赖的是偏移和规则本身。所以你会看到一个有趣的现象：正规的日历邀请（.ics 文件）里写的是 TZID:America/New_York，而不是 EST——专业工具早就绕开缩写了，只有人写给人看的邮件还在用。

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

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

国际日期变更线是弯的，还被改过。它大体沿 180 度经线，但一路拐弯，为的是不把一个国家劈成两天。基里巴斯在 1995 年把线东移，让全国日期统一，顺带成了世界上最早迎来新一天的地方；萨摩亚在 2011 年为了对齐澳新的工作日，直接跳过了一整天——那一年那个国家的日历上没有 12 月 30 日。

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

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

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