UTC 和 GMT 的区别是什么？

我有几个关于时区的问题:

  1. 时间可以单独用协调世界时来记录吗？
  2. UTC-6和 GMT-6是相同的吗? 这是否意味着它是美国本地时间？
  3. 比如，我的 UTC 时间是“02-01-201800:03”，这是否意味着我的美国本地时间是“01-01-201818:00”？

我搜索了维基百科和许多相关网站，但没有找到相关的解释。

156007 次浏览
小开
最佳答案

协调世界时和格林尼治平时之间没有时间差。

星期五上午7:17协调世界时是
星期五上午7:17，格林尼治平时(格林威治时间)

关键区别: UTC 和 GMT 都是时间标准，它们在派生和使用方面有所不同。

引用 Timeanddate.com的话:

格林尼治标准时间和协调世界时的区别:

格林尼治平时(gMT)经常被互换或混淆为 但格林尼治标准时间是一个时区，而协调世界时是一个协调世界时 时间标准。

尽管 GMT 和 UTC 在实践中共享相同的当前时间，但是存在 这两者之间的一个基本区别是:

  • 格林尼治标准时间是一些欧洲和非洲国家官方使用的时区。时间可以使用24小时格式(0-24)或12小时格式(上午1-12时/下午)显示。
  • 协调世界时不是一个时区，而是一个时间标准，它是世界各地民用时区和时区的基础。这意味着没有一个国家 地区正式使用协调世界时作为当地时间。
小开

天文学与原子钟

根据最初的定义，不同之处在于 格林威治时间(也被正式称为 世界时(UT)，这可能令人困惑)是基于天文观测，而 UTC 是基于原子钟。后来，GMT 至少在非正式场合被用来表示 UTC，这在一定程度上模糊了它们之间的区别。

GMT 代表 格林尼治平时，即英国东伦敦南岸 格林威治皇家天文台的平均太阳时。当太阳正好位于格林威治上空的最高点时，是格林威治标准时间中午12点。除了: 地球的自转稍微有点不均匀，所以中午12点被定义为一年的平均值，也就是太阳最高点的平均值。在格林尼治标准时间里，永远不会有任何闰秒，因为地球的自转不会跳跃。

UTC 在英语中代表协调世界时，由 原子钟定义，但在其他方面是相同的。在 UTC 中，秒的长度总是相同的。闰秒插入 UTC 以防止 UTC 和 GMT 漂移。相比之下，在格林尼治标准时间里，秒数是根据需要拉长的，所以原则上它们并不总是有相同的长度。

在大约100年的时间里，格林尼治标准时间被用作确定世界各地时间的基础。由于当今世界大多数时间的精确定义都是基于原子钟，所以时间的定义已经成为习惯，而是基于 UTC。

编辑: 格林尼治标准时间的最初含义现在有点没用了，但是三个字母的组合似乎并没有消失。我认为它的使用常常不考虑 UTC 是否真的是有意的，所以不要过分相信上面给出的严格定义。

回答你的问题:

  1. 是的，时间可以单独用协调世界时来捕捉。以 UTC 格式存储时间和使用 UTC 格式传输日期时间信息通常被认为是良好的做法。
  2. 我想这取决于美国各州如何定义自己的时代。我不知道，但我认为今天他们(官方或实际上)将时间定义为 UTC 的偏移量，而不是 GMT。两者之间的差异总是小于一秒钟，因此对于许多目的，您不需要关心。中央标准时间(例如美国/芝加哥时间)与 UTC-6(例如美国/丹佛时间)处于偏移 -6。另一方面，偏移 -6不一定意味着在美国的时间。当然，加拿大和墨西哥的部分地区也在使用，还有加拉帕戈斯群岛和复活节岛。
  3. 我不认为你得到的示例时间完全正确，但是是的，2018年1月2日世界协调时00:00的时间点与2018年1月1日18:00的时间点在芝加哥和其他地方是在世界协调时6的冬季(即冬季在北半球)。

进一步阅读:

小开

Something 接受答案既不正确也不有用。

相比之下，Ole V.V 的答案。正确地概括了技术上的差异ーー详细信息请参阅 Wikipedia 中详细页面的链接。

对于构建面向业务的应用程序的程序员来说，结果就是 UTC 是新的 GMT。你可以互换地使用这些术语，差别不超过一秒钟。因此，对于大多数应用程序的所有实际目的而言，没有任何区别。

下面是一些更实用的建议，包括代码示例。

绳子

比如，我的 UTC 时间是“02-01-201800:03”，这是否意味着我的美国本地时间是“01-01-201818:00”？

第一部分是一个糟糕的示例，日期时间字符串缺少其偏移量或区域的指示符。

如果字符串指示特定时刻，则它必须指示 时区(Continent/Region格式化的名称)和/或以小时-分钟-秒为单位的从 -UTC 的偏移量。如果字符串表示 UTC 本身的某个时刻，则表示从 UTC 的偏移量为零。

若要使用偏移量写入该字符串，可以应用各种约定。实践中最好的方法是同时使用小时和分钟以及冒号，例如 +00:00、 +05:30或 -08:00。前面的0和冒号都是可选的，但是我见过库在遇到诸如 -0800或 -8这样的值时中断。

祖鲁

作为零偏移量的快捷方式，字母 Z通常用来表示 UTC 本身。发音为 Zulu。

ISO 8601

此外，对于我们来说，以文本形式格式化用于计算的日期-时间的最佳实践是 ISO 8601标准格式。对于日期-时间格式，使用 YYYY-MM-DDTHH: MM: SS ± HH: MM: SS。T将日期部分与一天中的时间部分分隔开。这种格式有很多优点，比如非常明确，容易被机器解析，容易被不同文化背景的人阅读。另一个优点是按字母顺序排序也是按时间顺序的。该标准也接受 Z缩写。

因此，您的示例 UTC time as "02-01-2018 00:03"最好说成是 2018-01-02T00:03Z。

爪哇时间

要非常清楚，大多数编程语言、库和数据库对日期时间处理的支持非常差，这通常是基于对日期时间问题的不理解。处理日期时间非常复杂，而且很难掌握。

我遇到的唯一像样的库是与 Java8及更高版本捆绑在一起的 < em > java.time 类(参见 教程) ，以及它的前身 尤达时间项目(也是从 Java 松散地移植到。在 野田时光项目中使用 Net)。

在 爪哇时间中，一个矩以三种方式表示，它们的分辨率都是 纳秒。

  • Instant < br/> 始终使用 UTC。技术上，从1970年第一个时刻(1970-01-01 T00:00:00Z)的时代参考开始计算纳秒。
  • OffsetDateTime < br/> 在 UTC 之前或之后一定数量的小时-分钟-秒内的日期。
  • ZonedDateTime < br/> 在特定时区内带有时间的日期。

那么 时区和 从协调世界时偏移有什么区别呢？为什么我们需要单独的类？与 UTC 的偏移量只是一个小时-分钟-秒的数字，三个数字，不多也不少。很多中的时区更多。时区是过去、现在和未来的变化历史，用来抵消特定地区人们使用的偏移量。

什么改变？由他们的政治家的突发奇想或智慧所支配的变革。世界各地的政治家们已经表现出了改变他们管辖范围内的时区所使用的偏移量的倾向。夏时制是一种常见的变化模式，其时间表经常发生变化，制定或恢复 DST 的决定有时也会发生变化。其他的变化也发生了，比如在过去的几年中，朝鲜把他们的时钟调整了半个小时以便与韩国同步，委内瑞拉转向把他们的时钟调整了半个小时以便在不到十年之后向前跳跃，土耳其今年在几乎没有预警的情况下取消了原定的从 DST 到标准时间的变化，而现在的 俄罗斯在最近几年已经做了多次这样的变化。

回到第3点中的例子，让我们看看一些代码。

比如，我的 UTC 时间是“02-01-201800:03”，这是否意味着我的美国本地时间是“01-01-201818:00”？

您的示例字符串还有另一个问题。第一部分中的 03分钟被忽略了第二部分，一个明显的打字错误。我之所以知道，是因为在那个日期，美洲没有时区调整的影响，其中包括57分钟的小时。

一刻也没有

首先，我们解析您的输入字符串。由于缺少区域或偏移量的任何指示符，我们必须使用 LocalDateTime进行解析。LocalDateTime这个名称可能会引起误解，因为它确实意味着一个特定的地点。意思是任何地方或者所有地方。有关详细说明，请参阅 Instant 和 LocalDateTime 有什么区别。

String input = "2018-01-02T00:03" ;                  // Text of a date with time-of-day but without any context of time zore or offset-from-UTC. *Not* a moment, *not* a point on the timeline.
LocalDateTime ldt = LocalDateTime.parse( input ) ;   // Parsing the input as a `LocalDateTime`, a class representing a date with time but no zone/offset. Again, this does *not* represent a moment, is *not* a point on the timeline.

协调世界时

根据问题中给出的事实，我们知道这个日期和时间意在代表世界协调时的一个时刻。因此，我们可以为 UTC 本身分配从 UTC 偏移到0小时-分钟-秒的上下文。我们应用一个 ZoneOffset常量 UTC来得到一个 OffsetDateTime对象。

OffsetDateTime odt = ldt.atOffset( ZoneOffset.UTC );    // We are certain this text was intended to represent a moment in UTC. So correct the faulty text input by assigning the context of an offset of zero, for UTC itself.

时区

这个问题要求通过墙上的时钟看到这一时刻比美国使用的世界协调时晚六个小时。具有这种偏移量的一个时区是 America/Chicago。

指定 continent/region格式的 正确的时区名称，如 America/Montreal、 Africa/Casablanca或 Pacific/Auckland。不要使用2-4个字母的缩写，如 CST、 EST或 IST，因为它们是 没有真正的时区，不标准化，甚至不唯一(!).

ZoneId z = ZoneId.of( "America/Chicago" ) ; // Adjust from UTC to a time zone where the wall-clock time is six hours behind UTC.
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;

看这个 代码在 IdeOne.com 上运行。

ToString () : 2018-01-02 T00:03Z

ToString () : 2018-01-01 T18:03-06:00[ America/Chicago ]

同样的时间，不同的挂钟时间

这个 odt和 zdt都代表同一时刻，同一时间点。唯一的区别就是挂钟的时间。

让我们来举一个例子，使用冰岛的时区使用从 UTC 的偏移量0小时-分钟-秒。因此，区域 Atlantic/Reykjavik的挂钟时间与 UTC 相同。至少现在他们的挂钟时间与世界协调时相匹配; 在过去或将来，它可能是不同的，这就是为什么说“世界协调时 是冰岛的时区”是不正确的。无论如何，我们的例子... 说有人在 冰岛雷克雅未克与午夜后3分钟挂在他们的墙上的时钟打电话给某人在美国。那个美国人住在一个使用芝加哥地区时区的地方。当接电话的人拿起电话时，他们会抬头看一眼挂在墙上的时钟，看看时间刚过下午6点(18:03)。同样的时间，不同的挂钟时间。

此外，挂在他们墙上的日历也不同，因为在冰岛是“明天”，而在美国本土是“昨天”。同一时刻，不同日期！

Table of date-time types in Java, both modern and legacy.

关于 爪哇时间

< em > java.time 框架内置于 Java8及更高版本中。这些类取代了令人讨厌的旧的 遗产日期时间类，如 java.util.Date、 Calendar和 SimpleDateFormat。

现在在 维修模式中的 尤达时间项目建议迁移到 爪哇时间类。

要了解更多，请参阅 < em > Oracle 教程 。并搜索堆栈溢出许多例子和解释。规范是 JSR 310。

您可以直接与数据库交换 爪哇时间对象。使用与 JDBC 4.2或更高版本兼容的 JDBC 驱动程序。不需要字符串，不需要 java.sql.*类。

从哪里获得 java.time 类？

Table of which java.time library to use with which version of Java or Android

< strong > Three Ten-Ultra 项目使用其他类扩展 java.time。这个项目是将来可能添加 java.time 的试验场。您可以在这里找到一些有用的类，比如 Interval、 YearWeek、 YearQuarter和 更多。

小开

格林威治时间是在格林威治子午线计算的平均太阳时间

协调世界时是基于铯原子钟极其有规律的“滴答声”

它们是基于 都不是的同时 也没有以同样的方式计算出来的。恕我直言，关于 https://currentmillis.com的措辞充其量是误导性的，如果不是完全错误的话。


提交答案