UTC和GMT之间有什么区别？

Question

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

1. 时间能否仅以UTC表示
2. UTC-6和GMT-6是否相同，这是否意味着现在是美国当地时间
3. 比如，我的UTC时间是“02-01-2018 00:03”，这是否意味着我的美国当地时间是“01-01-2018 18:00”

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

Answer 1

协调世界时和格林威治标准时之间没有时差。

协调世界时（UTC）周五上午7:17是格林威治标准时间（GMT）周五上午7:17

关键区别：UTC和GMT都是时间标准，它们的推导和使用都不同。

引用时间和日期。通用域名格式：

GMT和UTC之间的差异：

格林威治标准时间（GMT）经常与协调世界时（UTC）互换或混淆。但GMT是一个时区，UTC是一个时间标准。

虽然GMT和UTC在实践中共享相同的当前时间，但两者之间有一个基本区别：

• GMT是一些欧洲和非洲国家正式使用的时区。可以使用24小时格式（0-24）或12小时格式（1-12 am/pm）显示时间

Answer 2

❌ 被接受的答案既不正确也不有用。

✅相比之下，Ole V. V.的答案正确地总结了技术差异——详情请点击维基百科详细页面的链接。

对于开发面向业务的应用程序的程序员来说，其结果是UTC是新的GMT。您可以互换使用这些术语，其差异实际上不到一秒钟。因此，对于大多数应用程序的所有实际用途而言，没有任何区别。

下面是一些更实用的建议，并附有代码示例。

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

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

如果字符串表示特定时刻，则它必须表示时区（大陆/地区格式名称）和/或以小时-分-秒为单位的UTC偏移量。如果字符串表示UTC本身的一个时刻，则表示与UTC的偏移量为零。

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

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

此外，在我们看来，将日期时间文本化用于计算的最佳实践是ISO 8601标准格式。日期时间使用YYYY-MM-DDTHH:MM:SS±HH:MM:SS格式。T将日期部分与时间部分分开。这种格式有很多优点，比如基本上不含糊，易于机器解析，易于跨文化阅读。另一个优点是按字母顺序排序也按时间顺序排序。本标准也接受Z缩写。

因此，您的示例UTC时间为“02-01-2018 00:03”最好表述为2018-01-02T00:03Z。

请注意，大多数编程语言、库和数据库对日期时间处理的支持非常差，通常是基于对日期时间问题的理解不足。处理日期时间令人惊讶地复杂且难以掌握。

我遇到的唯一像样的库是java。时间类（参见教程）与Java8及更高版本捆绑在一起，其前身是Joda time项目（在Noda time项目中也从Java松散地移植到了.Net）。

在java.time中，一个时刻有三种表现方式。所有这些都有纳秒的分辨率。

• Instant
  始终在UTC中。从技术上讲，自1970 (1970-01-01T00:00:00Z）的第一个时刻的纪元引用以来的纳秒计数。
• OffsetDateTime
  在UTC之前或之后一定小时-分钟-秒的上下文中具有一天中的时间的日期。
• ZonedDateTime
  在特定时区的上下文中具有一天中的时间的日期。

那么时区和UTC偏移量之间的区别是什么呢？为什么我们需要分开上课？与UTC的偏移量只是小时分秒数，三个数字，不多也不少。一个时区要多得多。时区是特定地区人民使用的偏移量的过去、现在和未来变化的历史。

什么变化？由政客的奇思妙想或智慧决定的变化。世界各地的政界人士都倾向于改变其管辖范围内时区使用的偏移量。夏时制（DST）是一种常见的变化模式，其时间表经常发生变化，制定或恢复夏时制的决定有时也会发生变化。其他变化也在发生，比如，就在过去几年里，朝鲜将时钟改为半小时，以与韩国同步，委内瑞拉将时钟改为半小时，但不到十年后才向前跳，土耳其今年取消了原定从DST改为标准时间的计划，几乎没有预先警告，而当代俄罗斯近年来也做出了多次这样的改变。

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

比如，我的UTC时间是“02-01-2018 00:03”，这是否意味着我的美国当地时间是“01-01-2018 18: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本身指定从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.

这个问题要求通过一个落后于美国UTC六小时的挂钟来观察这一时刻。有这样一个偏移的时区是美国/芝加哥。

以大陆/地区的格式指定适当的时区名称，例如美国/蒙特利尔，非洲/卡萨布兰卡，或太平洋/奥克兰。切勿使用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 ) ;

查看此代码在IdeO上实时运行ne.com.

奥德特。toString（）：2018-01-02T00:03Z

zdt。toString（）：2018-01-01T18:03-06:00[美国/芝加哥]

这个odt和zdt都代表着相同的同时时刻，时间线上的相同点。唯一的区别是墙上的时钟时间。

让我们举一个例子，在冰岛，他们的时区与UTC的偏移量为0小时分秒。因此大西洋/雷克雅未克地区的挂钟时间与UTC相同。至少在今天，他们的挂钟时间与UTC相匹配；在过去或未来，它可能会有所不同，这就是为什么说“UTC是冰岛的时区”是不正确的。无论如何，我们的例子是……比如说，冰岛雷克雅未克的一个人，墙上挂着午夜3分钟后的时钟，他给美国的一个人打了一个电话。那个美国人住在一个使用芝加哥地区时区的地方。当被叫人拿起电话时，他们抬头看了看挂在墙上的时钟，发现时间刚刚过了下午6点（18:03）。同一时刻，不同的挂钟时间。

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

爪哇。时间框架内置于Java8及更高版本中。这些类取代了麻烦的旧遗留日期时间类，比如java。util。日期，日历，

Joda Time项目现在处于维护模式，建议迁移到java。时间课。

要了解更多信息，请参阅Oracle教程。并在Stack Overflow中搜索许多示例和解释。规范是JSR 310。

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

在哪里可以获得java。时间课？

• JavaSE8、JavaSE9、JavaSE10、JavaSE11及更高版本——标准JavaAPI的一部分，带有捆绑实现。

• 大多数java.time功能被反向移植到Java6

• 更高版本的Android捆绑包实现了java。时间课

额外的Three Ten项目扩展了java。有额外课程的时间。这个项目是java未来可能增加的一个试验场。时间你可以在这里找到一些有用的类，比如Interval，YearWeek，YearQuarter，等等。

Answer 3

根据最初的定义，区别在于GMT（也被正式称为世界时（UT），这可能令人困惑）是基于天文观测，而UTC是基于原子钟。后来GMT至少被非正式地用来指代UTC，这在一定程度上模糊了区别。

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

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

大约100年来，格林尼治标准时间被用作世界各地定义时间的基础。由于当今世界大多以原子钟为基础来精确定义时间，因此习惯上以UTC为基础来定义时间。

编辑：如今，GMT的原意有些无用，但三个字母的组合似乎并没有消失。我认为它的使用往往与UTC是否真的是有意的无关，所以不要过于相信上面给出的严格定义。

对于您的问题：

1. 是的，时间可以仅在UTC中捕获。将时间存储在UTC中并使用UTC传输日期-时间信息通常被认为是良好的做法。
2. 我想这取决于美国每个州来定义它的时间。我不知道，但我想今天他们（官方或实践中）将时间定义为与UTC而不是GMT的偏移量。两者之间的差异总是小于一秒，因此在许多情况下您无需在意。中央标准时间（例如美国/芝加哥）位于偏移量-6，山地日光时间（例如美国/丹佛）也是如此。另一方面，偏移量-6并不一定意味着美国的时间。当然，加拿大和墨西哥的部分地区也使用它，加拉帕戈斯和复活节岛也使用它。
3. 我不认为你的示例时间完全正确，但是是的，2018年1月2日00:00 UTC与2018年1月1日18:00在芝加哥和其他冬季UTC-6的地方是相同的时间点（即北半球的冬天）。

进一步阅读：

• 时间系统
• 当前的百万分之一是UTC和GMT的简单和复杂对比