UTC和GMT之间的差异

Question

嗨我对时区的疑问很少:

1. 可以仅用UTC捕获时间吗？
2. UTC -6和GMT -6是否相同,这是否意味着它是美国当地时间？
3. 比如,我的UTC时间为"02-01-2018 00:03"这是否意味着我的美国当地时间是"01-01-2018 18:00"？

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

Answer 1

天文学与原子钟

不同之处在于GMT(也称为通用时间(UT),可能令人困惑)基于天文观测,而UTC则基于原子钟.

GMT代表格林威治标准时间,即英国东伦敦南岸格林威治皇家天文台的平均太阳时.当太阳位于格林威治正上方的最高点时,格林威治标准时间中午12点.除了:地球略微不均匀地旋转,因此中午12被定义为年平均值,即太阳最高时的平均值,它的高潮.在GMT中,永远不会有任何闰秒,因为地球的旋转不会跳跃.

UTC代表英语协调世界时,由原子钟定义,但在其他方面相同.在UTC中,第二个总是具有相同的长度.以UTC 格式插入闰秒,以防止UTC和GMT分开.相比之下,在GMT中,根据需要延长秒数,因此原则上它们并不总是具有相同的长度.

在100年的时间里,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相同的时间点相同冬天(北半球的冬天,即).

进一步阅读:时间系统.

Answer 2

？该接受的答案既不是正确的也没有什么用处。

？相反，Ole VV的Answer正确地总结了技术差异-有关详细信息，请访问Wikipedia中详细页面的链接。

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

这是一些更实用的建议，以及代码示例。

弦乐

假设我的UTC时间为“ 02-01-2018 00:03”，这表示我的美国当地时间为“ 01-01-2018 18:00”吗？

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

如果字符串指示特定时刻，则必须指示时区（Continent/Region秒数的形式格式名称）和/或距UTC的偏移量。如果该字符串用于表示UTC本身的时刻，则表示相对于UTC的偏移为零。

为了以偏移量写入该字符串，可以应用各种约定。在实践中最好是与两个小时和分钟以冒号沿，如+00:00，+05:30，或-08:00。前导零和冒号都是可选的，但是我已经看到库在遇到诸如-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。

java.time

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

我遇到的唯一一个不错的库是与Java 8和更高版本捆绑在一起的java.time类（请参阅教程），以及它的前身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时间晚六小时的挂钟时间来了解这一刻。具有此类偏移的一个时区为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实时运行此代码。

odt.toString（）：2018-01-02T00：03Z

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

相同的时刻，不同的时钟时间

这odt与zdt双方代表相同的同时时刻，在时间轴上的相同点。唯一的区别是挂钟时间。

让我们工作一个例子，使用冰岛，其时区使用零时分分钟秒的UTC偏移量。因此，该区域Atlantic/Reykjavik的挂钟时间与UTC相同。至少目前，他们的挂钟时间与UTC匹配；在过去或将来可能会有所不同，这就是为什么说“ UTC 是冰岛的时区”是不正确的。无论如何，以我们的例子为例……说一个在冰岛雷克雅未克的人在午夜3点钟挂在他们墙上的时钟上打了个电话给美国某人。该美国人居住在使用芝加哥地区时区的地方。当被叫人拿起电话时，他们抬头看挂在墙上的时钟，发现时间刚好是下午6点（18:03）。相同的时刻，不同的时钟时间。

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

关于java.time

该java.time框架是建立在Java 8和更高版本。这些类取代麻烦的老传统日期时间类，如java.util.Date，Calendar，和SimpleDateFormat。

现在处于维护模式的Joda-Time项目建议迁移到java.time类。

要了解更多信息，请参见Oracle教程。并在Stack Overflow中搜索许多示例和说明。规格为JSR 310。

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

在哪里获取java.time类？

• Java SE 8， Java SE 9， Java SE 10， Java SE 11和更高版本-标准Java API的一部分，具有捆绑的实现。
  • Java 9添加了一些次要功能和修复。
• Java SE 6和 Java SE 7
  • 大多数java.time功能都在ThreeTen- Backport中反向移植到Java 6和7 。
• 安卓系统
  • 更高版本的Android捆绑了java.time类的实现。
  • 对于早期的Android（<26），ThreeTenABP项目改编了ThreeTen-Backport（如上所述）。请参阅如何使用ThreeTenABP…。

该ThreeTen-额外项目与其他类扩展java.time。该项目为将来可能在java.time中添加内容提供了一个试验场。你可能在这里找到一些有用的类，比如Interval，YearWeek，YearQuarter，和更多。

Answer 3

格林尼治标准时间（格林尼治标准时间）星期五，格林尼治标准时间（格林尼治标准时间）星期五7:17，格林尼治标准时间（UTC），格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间，格林尼治标准时间。

主要区别： UTC和GMT都是时间标准，它们的派生和使用方式都不同。

引用timeanddate.com：

GMT和UTC之间的区别：

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

尽管实际上GMT和UTC在当前时间共享相同的时间，但两者之间存在根本的区别：

• GMT是在某些欧洲和非洲国家中正式使用的时区。可以使用24小时格式（0-24）或12小时格式（1-12 am / pm）来显示时间。
• UTC不是时区，而是作为全球民用时间和时区基础的时间标准。这意味着没有任何国家或地区正式使用UTC作为当地时间。

Answer 4

GMT 是根据格林威治子午线计算的平均太阳时。https://www.rmg.co.uk/discover/explore/greenwich-mean-time-gmt

UTC 基于铯原子钟极其规则的“滴答声”。https://en.wikipedia.org/wiki/Cooperative_Universal_Time

它们既不是基于相同的时间，也不是以相同的方式计算。恕我直言， https://currentmillis.com上的措辞充其量是具有误导性的，即使不是完全错误。