GMT 转 UTC 格林尼治平时 ↔ 协调世界时 免费 在线 安全
格林尼治平时 和 协调世界时 在钟面上读数完全一样——时差是零。填一个 GMT 的时间,它会原样以 UTC 回来,这就是老实的答案;两个名字究竟差在哪里,下面写着。
一整天 — GMT 转 UTC (格林尼治平时 ↔ 协调世界时)
| GMT | UTC |
|---|---|
| 00:00 | 00:00 |
| 03:00 | 03:00 |
| 06:00 | 06:00 |
| 09:00 | 09:00 |
| 12:00 | 12:00 |
| 15:00 | 15:00 |
| 18:00 | 18:00 |
| 21:00 | 21:00 |
这些单位从哪里来
直到十九世纪中叶,每座城镇还各守各的正午,由头顶的太阳定下,没人在意邻镇慢了四分钟。终结这一切的是铁路:时刻表没法照着一百个地方的正午来写。1847年英国把铁路统一到格林尼治时间,1884年华盛顿的国际子午线会议选定格林尼治为本初子午线,并勾出我们今天仍在用的二十四时区方案。格林尼治平时一直是世界的基准,直到1972年由协调世界时取代:协调世界时由原子钟保持,再用闰秒把它系回转动的地球。本页的缩写指的是标准时,也就是冬季的设定——正因如此,每一个都是固定的小时数,而不是随年份游移的东西。
你会在哪里遇到它们
当两个身处异地的人必须就同一刻达成一致时,时区才成为实在之物:两间办公室之间的通话、起飞之前就落地的航班、你熟睡时开市的交易所、写在别人下午里的截止期限。服务器日志、列车与航班时刻表,以及一切带时间戳的东西,都以协调世界时保存,正是为了让这个问题随时能有定论,不论墙上挂的是谁的钟。
常见问题
那夏令时呢?
这里的时差是标准时的时差,也就是一个时区在冬季所守的设定。实行夏令时的地方,同样的地点在一年中的一段时间里会再往前拨一小时,名字也随之改变:中欧时间变成中欧夏令时间,Eastern Standard Time 变成 Eastern Daylight Time。各国换算的日期并不相同,南北两个半球又在相反的月份调整;因此若日期落在夏令时期内,请给实行它的那一方加上一小时。
为什么并非每个时差都是整小时?
因为时差由各国政府决定,而不是由几何决定。印度与整点差半小时,为 UTC+05:30;尼泊尔差四分之三小时,为 UTC+05:45;查塔姆群岛为 UTC+12:45。其中任何一个都可以由法律改动,近年来也有几个国家挪动过自己的时差。
结果精确吗?
两个单位若以整数互相定义,那就是精确的——本页在数字上方说明了这一点,唯一的舍入在于显示多少位。若比值没有有限小数,本页给出十二位有效数字,并说明这个关系是近似的,而不是装作不是。
我敲进去的东西会离开我的设备吗?
不会。运算在你的浏览器里进行;没有任何东西被上传,也没有接收它的服务器。页面加载一次之后,断网也照样能用。
当审计员要求 UTC 而您的笔记写的是 GMT
这发生在合规审查、API 文档和团队之间的交接说明里。有人写了“维护窗口:22:00 到 23:30 GMT”,另一个人需要用 UTC 写出同一个窗口。如果您被要求把 GMT 换算成 UTC,诚实的回答是数字保持不动。22:00 GMT 是 22:00 UTC,23:30 GMT 是 23:30 UTC。两种刻度之间的偏移为零,日期也从不移动。
这并不让这个问题变得愚蠢。这两个名称有不同的历史、不同的所有者以及在软件中不同的怪癖,草率的改写可能引入错误。本页给您规则、一组实例读数、每个名称背后的故事、软件错误标注它们的地方,以及一份简短的规则清单,用来书写没有人会读错的时间。所有算术都在您的浏览器中进行。
换算的步骤
写什么
读出 GMT 一侧的小时和分钟,在 UTC 一侧写下相同的小时和分钟。当您把 GMT 换算成 UTC 时,您加的是零分钟。因此 GMT 一侧的 22:00 到 23:30 区间在 UTC 一侧就是 22:00 到 23:30,跨越午夜的区间依然在完全相同的地方跨越它。
用来对照的读数
01:10 GMT 是 01:10 UTC。05:50 GMT 是 05:50 UTC。10:25 GMT 是 10:25 UTC。14:00 GMT 是 14:00 UTC。17:35 GMT 是 17:35 UTC。22:00 GMT 是 22:00 UTC。如果上面的方框对其中任何一个显示了别的结果,那说明发生的是这个换算之外的事。
仍需第二步的情形
“那在我的手表上是几点?”这个问题需要不同的偏移。布加勒斯特的人冬季加两小时,夏季加三小时。芝加哥的人冬季减六小时,夏季减五小时。本页的换算止于共同的参考,把那一步留给您。
GMT 的故事
从海图到铁路时刻表
1714 年的《经度法案》为找到船舶位置的可靠方法提供了一大笔奖金,而获胜的想法是一台在船航行时保持母港时间的时钟。约翰·哈里森的航海天文钟在 1760 年代初经过测试,使这变得可行,对英国船只来说,母港时间就是格林尼治的时间。铁路后来需要全国统一的时间,到 1840 年代,大多数英国铁路线按格林尼治时间运行。1880 年的一项法律使之成为正式。
世界就子午线达成一致
1884 年在华盛顿举行的国际子午线会议上,二十五个代表团中的二十二个投票支持格林尼治作为本初子午线。圣多明各投了反对票,法国和巴西弃权。在接下来的大半个世纪里,GMT 成为海图和国际电报时刻表的共同参考。
今天
皇家天文台仍矗立在格林尼治公园,游客在那里给黄铜线拍照,尽管实际的天文工作在 1950 年代就迁走了。GMT 作为英国和爱尔兰的法定冬季时间、冰岛和几个西非国家的永久时钟,以及许多协议内部的标签而保留下来。
UTC 的故事
为什么需要一个新名称
到 1950 年代,最初的原子钟表明地球自转并不完全稳定,所以基于太阳的时间刻度无法服务于物理学、无线电和导航。1960 年出现了第一个把原子秒与地球自转结合的系统,而 UTC 目前的形式始于 1972 年。它的缩写是英语和法语词序之间的折中。
由谁保管
巴黎附近的国际计量局综合数十个国家实验室的时钟读数。然后每个国家调控自己的 UTC 版本,使之与综合值保持在十亿分之几秒之内。结果通过无线电信号、卫星导航系统和网络时间服务器到达公众。
它为您做什么
UTC 是日志、数据库和飞行计划对齐的唯一一列。每当您把 GMT 换算成 UTC,您是从一个历史名称转到技术名称,而不扰动读数。
并排阅读 GMT 与 UTC
实际上的等价
两种刻度在设计上彼此保持在一秒之内,所以对于任何涉及日程、记录或交谈的任务,偏移都是零。词典、标准机构和操作系统都把 GMT 列为 UTC 的同义词,正是出于这个原因。
词汇分歧之处
撰写规范的人更喜欢 UTC,因为它命名的是一个被测量的标准。记者和旅行者更喜欢 GMT,因为它是更古老、更友好的词。两种选择都不改变小时。当您的目标文档要求 UTC 时,替换标签,数字不要动:这就是您把 GMT 换算成 UTC 时的全部工作。
唯一会花钱的差别
七月里说“GMT”的人常常是在谈论伦敦的时钟,它比真正的 GMT 快一小时。请把它当作关于伦敦的陈述,而不是关于 GMT 的陈述,并单独换算。
夏令时,以及谁在实行
英国和爱尔兰的日历
联合王国的时钟在三月最后一个星期日的 01:00 UTC 拨快,在十月最后一个星期日的 01:00 UTC 拨回。2026 年即三月 29 日和十月 25 日。爱尔兰遵循同样的日期。在两者之间,挂钟上的标签在英国是英国夏令时,在爱尔兰是爱尔兰标准时间,二者都是 UTC+1。
爱尔兰法律的一个奇特角落
爱尔兰法律把夏季定义为标准时间,并把冬季时钟视为 GMT。时区数据库把这表示为冬季一个负的夏令时偏移。对您来说效果是一样的:都柏林冬季是 UTC+0,夏季是 UTC+1,与伦敦相同。
对换算意味着什么
GMT 和 UTC 自身没有任何变化,您可以在一年中的任何日期把 GMT 换算成 UTC。只有关于英国或爱尔兰挂钟的陈述才需要对照日历检查。
软件如何命名这些时区
Windows
Windows 的时区列表包含三个相似的条目。“UTC”是固定的零偏移。“Greenwich Standard Time”,用于蒙罗维亚和雷克雅未克,也固定在零。“GMT Standard Time”,用于伦敦、都柏林、爱丁堡和里斯本,遵循夏令时。设为第三个的服务器每年会移动一小时两次,这让那些选它时期望全年都是 GMT 的人吃惊。
Unix 与时区数据库
在 Linux 和 macOS 上,名称 UTC、GMT、Etc/UTC、Etc/GMT 和 Zulu 都固定在零。真实的地方有它们自己的条目:Europe/London、Europe/Dublin、Atlantic/Reykjavik。对于记录事件的服务器,选 UTC 并保持。对于需要本地视图的人,选一个城市。
Java、JavaScript 和 Python
每种语言如何对待这一对
Java 提供 ZoneOffset.UTC 和 ZoneId.of("GMT"),它们在算术上行为相同。JavaScript 在 toUTCString() 中用后缀 GMT 打印 UTC 日期,在 toISOString() 中用字母 Z。Python 的 timezone.utc 和 ZoneInfo("GMT") 都给出固定的零偏移。因此必须把 GMT 换算成 UTC 的例程归结为原样返回输入。
不要把标签写死
如果您的代码存储时间,请把它们存为时刻,而不是字符串。这样显示时就没有人需要在 GMT 和 UTC 之间做选择,您的用户会看到界面偏好的任何标签。
船舶日志与海洋
格林尼治时间的传统
自天文钟时代以来,船舶一直以格林尼治时间记航海日志,因为它给了每艘船一个不依赖于所航行大洋的共同参考。现代的驾驶台系统和遇险信息则记录 UTC,而航海者在交谈中仍说 GMT。
为什么在岸上仍然重要
引用“ETA 06:00 GMT”的航运时刻表与期望 06:00 UTC 的港口系统描述的是同一个时刻。当您把 GMT 换算成 UTC 时,可以把数字直接传过去,然后为港务办公室加上当地偏移。
天气报告
天气图的观测时刻
气象部门在一天的固定钟点收集观测,传统上称为 00、06、12 和 18 GMT,现在称为 UTC。标着“12Z”的图是由该刻度上 12:00 的观测构建的。您所在地区的预报可能稍后发布,但它的参考时间在全世界都一样。
本地解读
在罗马尼亚,12 UTC 冬季是 14:00,夏季是 15:00。在伦敦,12 UTC 冬季是 12:00,夏季是 13:00。在芝加哥,冬季是 06:00,夏季是 07:00。标签中没有任何东西告诉您适用哪一个,所以请把日期与图表放在一起。
格林尼治报时球与报时音
公众获知时间的两种方式
自 1833 年起,一个红球每天在皇家天文台于一点钟沿桅杆落下,这样泰晤士河上的船只可以校准它们的天文钟。1924 年,BBC 开始向全国广播六个短音,即格林尼治时间信号。两者曾经都是简单的 GMT 服务。今天的无线电信号遵循英国实行的时钟,冬季是 GMT,夏季是 BST。
对现代书写的启示
这些信号教会数百万人把格林尼治这个词等同于他们厨房时钟上的时间,这个习惯就是为什么“GMT”仍然出现在真正意思是“伦敦时间”的消息中。
文档、标准和风格指南
风格指南怎么说
技术风格指南告诉作者写 UTC,按年-月-日的顺序给出日期,并避免“午夜”或“正午”这样的含糊词语,除非同时给出日期。这个建议来自 ISO 8601,它还定义了记法 2026-10-13T22:00:00Z。
改写旧文档
在较旧的手册中,搜索 GMT,检查每处提及说的是机器或协议而不是伦敦,然后把标签替换为 UTC。数字保持不变。当您对整本手册把 GMT 换算成 UTC 时,这条规则涵盖了几乎每一行。
会议、网络研讨会和发布会
发布一个锚定时间
邀请全世界人参加的组织者应当发布一个单一的锚点,如“十月 13 日星期二,15:00 UTC”,把本地对应时间留给换算器或日历文件。这样就避免了一半观众因为组织者想着伦敦的夏季时钟而提早一小时到场的场面。
同一页上的本地对应时间
一张小表会有帮助:布加勒斯特在十月 25 日改时钟之前是 18:00,芝加哥 10:00,孟买 20:30,东京次日 00:00。从 UTC 计算每一个可避免连环换算,而连环换算正是错误滋生之处。
机场与航班时刻表
飞行员的时钟
驾驶舱和管制塔以 UTC 工作,飞行员称之为 Zulu。飞行计划、预报和航行通告都这样盖章。像“ETD 1830Z”这样的一行表示 18:30 UTC,对旅行者来说,在布加勒斯特冬季是 20:30,夏季是 21:30。
您手中的机票
登机牌列出当地时间,所以飞行员的文件和您的文件使用不同的时钟。比较它们需要机场在那个日期的当地偏移。从 GMT 到 UTC 的这一步没有给这项工作增加任何东西,所以您可以先把 GMT 换算成 UTC,之后再去操心机场。
不改变时钟的国家
全年 GMT 的名单
冰岛全年保持 UTC+0,尽管位置如此偏西,太阳最高的时刻远在一点钟之后。加纳、塞内加尔、马里、几内亚、塞拉利昂、利比里亚和科特迪瓦也是如此。在这些地方,说 GMT 的人在一年中的任何时候都是对的。
改走别的路的国家
欧洲和非洲西侧的一些国家在上个世纪随政治选择的变化而改变过时区。葡萄牙在零和快一小时之间切换过不止一次,西班牙在 1940 年改用了中欧时间。处理旧数据时,请查看具体地方的历史。
对您自己笔记的快速审计
三个问题
来源描述的是机器还是人?日期是否落在三月最后一个星期日与十月最后一个星期日之间?您的目标需要标签、数字偏移还是城市?回答这些问题,您就会知道该通过复制还是通过调整来把 GMT 换算成 UTC。
如有疑问,写出偏移
像 22:00+00:00 这样的记法写明了偏移本身,没有人能对此提出异议。每一个您可能遇到的日期解析器也都接受它。
跨大西洋的混合团队
为什么差别不是恒定的
美国在三月的第二个星期日开始夏令时,在十一月的第一个星期日结束。欧洲在三月的最后一个星期日开始,在十月的最后一个星期日结束。2026 年美国在三月 8 日拨动,欧洲在三月 29 日跟进。有三周伦敦与纽约之间的差别是四小时而不是五小时。
为什么 UTC 是中立方
双方都可以用 UTC 描述同一个事件。在您把 GMT 换算成 UTC 之后,每一方加上自己的偏移,没有任何一方依赖另一方对时钟做了什么。
客服台与追随太阳的模式
一份排班,多个办公室
全球客服台随着白天绕地球移动,把工单从一个办公室交给另一个办公室。排班表只用 UTC 写一次,并以各办公室的当地时间显示。因为 UTC 从不移动,经理们可以在一月编辑排班表,并相信它在七月仍然有效,尽管当地时钟已经移动。
一个例子
澳大利亚的班次在 06:00 UTC 结束,罗马尼亚的班次从 06:00 到 14:00 UTC,德克萨斯的班次在 14:00 UTC 接手。在当地,罗马尼亚的班次冬季是 08:00 到 16:00,夏季是 09:00 到 17:00。把排班表写成 GMT 而不是 UTC 的团队给出相同的小时,快速把 GMT 换算成 UTC 可以确认这一点。
手工检查您自己的换算
两分钟,不用工具
任取一个读数,比如 17:35 GMT。把它写成 17:35 UTC 的形式。把两者拿去对照一个设为零偏移的可信时钟。它们吻合。然后问当时伦敦的日期是什么,以及伦敦人指的是挂钟还是零偏移刻度。第二个问题承载了全部风险。
何时停止检查
如果来源是日志、协议、证书或科学时间表,您在第一步之后就可以停止。如果来源是一个谈论夏季伦敦的人,请单独换算。
清单:如何安全地把 GMT 换算成 UTC
之前
确认来源
机器、协议还是人?这一个事实决定一切。
确认目的地
如果它要求 UTC,复制读数。如果它要求本地时间,计划第二步。
之后
检查结果
小时、分钟和日期应当与输入一致。任何差别都表明是另一种换算。
记录下来
写下日期、读数和标签 UTC。在公开文档中加上本地对应时间。
人们在把 GMT 换算成 UTC 时犯的错误
在夏季减去一小时
这种冲动很强,因为七月伦敦快一小时。但 GMT 与 UTC 之间的偏移在七月和一月一样为零。
在服务器上选了 GMT Standard Time
这个 Windows 条目遵循夏令时。它不是固定的零时区。如果您想要稳定的时钟,请选 UTC。
把 Etc/GMT+3 读成快三小时
在那种命名方案中符号是反的,Etc/GMT+3 比 UTC 慢三小时。
写时间不带日期
没有日期的时间无法对照日历核实,所以对处于英国夏令时的人来说可能差一小时。
关于 GMT 和 UTC 的问题
把 GMT 换算成 UTC 时我要加什么?
什么都不加。偏移是零小时。
为什么标准要求 UTC?
因为 UTC 是被测量的、国际维护的刻度,也因为它避免了伦敦夏令时的含糊。
GMT Standard Time 与 UTC 相同吗?
不同。在 Windows 中它遵循英国夏令时,所以不是固定的。
日期会变吗?
不会。换算保持日期。
我的输入会被发送到服务器吗?
不会。一切都在您的浏览器中运行。
更多时区换算
值得一看的其他换算器:GMT 转 PST、GMT 转 CST、CST 转 UTC、WET 转 UTC、UTC 转 CET、CET 转 GMT、CST 转 PST、EST 转 UTC、GMT 转 CET。要换到相反方向,请看UTC 转 GMT。
因此,要把 GMT 换算成 UTC,您复制读数并更换标签。把伦敦的夏季时钟放在心里单独的一个盒子里,整个主题就归结为一条规则。计算在本地进行,免费,无需账户。