UTC 和 GMT 有什么区别？
What is the difference between UTC and GMT?
我有一些关于时区的问题：
- 是否可以单独使用 UTC 捕获时间？
- UTC -6 和 GMT -6 是否相同，是否意味着它是美国当地时间？
- 比如说，我的 UTC 时间是“02-01-2018 00:03”，这是否意味着我的美国当地时间是“01-01-2018 18:00”？
我在维基百科和许多相关网站上搜索过，但没有找到相关的解释。
协调世界时和格林威治标准时间之间没有时差。
7:17 星期五上午，协调世界时 (UTC) 是
7:17 格林威治标准时间 (GMT) 星期五上午
主要区别：UTC 和 GMT 都是时间标准，在派生和使用方面有所不同。
The Difference Between GMT and UTC:
Greenwich Mean Time (GMT) is often interchanged or confused with
Coordinated Universal Time (UTC). But GMT is a time zone and UTC is a
time standard.
Although GMT and UTC share the same current time in practice, there is
a basic difference between the two:
- GMT is a time zone officially used in some European and African countries. The time can be displayed using both the 24-hour format (0 - 24) or the 12-hour format (1 - 12 am/pm).
- UTC is not a time zone, but a time standard that is the basis for civil time and time zones worldwide. This means that no country or
territory officially uses UTC as a local time.
天文学与原子钟
根据最初的定义，不同之处在于 GMT (also officially known as Universal Time (UT)，这可能会造成混淆）是基于天文观测，而 UTC 是基于原子钟。后来 GMT 至少被非正式地用来指代 UTC，这在某种程度上模糊了区别。
GMT代表格林威治标准时间，英国伦敦东部南岸Royal Observatory in Greenwich的平太阳时。当太阳位于格林威治正上方的最高点时，是格林尼治标准时间中午 12 点。除了：地球自转略微不均匀，所以中午 12 点被定义为年平均值，即太阳处于最高点时的平均值。在 GMT 中，永远不会有任何闰秒，因为地球的自转不会跳跃。
UTC, which stands for Coordinated Universal Time in English, is defined by atomic clocks, but is otherwise the same. In UTC a second always has the same length. Leap seconds 被插入到 UTC 中以防止 UTC 和 GMT 漂移分开。相比之下，在 GMT 中，秒数会根据需要延长，因此原则上它们的长度并不总是相同。
在大约 100 年的时间里，格林威治标准时间被用作定义世界各地时间的基础。由于当今世界大多基于原子钟来精确定义时间，因此习惯上以 UTC 来定义时间。
编辑：GMT 的本意如今有些无用，但三个字母组合似乎并没有消失。我认为它经常被使用而不考虑UTC是否真的有意，所以不要太相信上面给出的严格定义。
您的问题：
- 是的，可以单独使用 UTC 捕获时间。以 UTC 格式存储时间并使用 UTC 传输 date-time 信息通常被认为是好的做法。
- 我想这取决于美国的每个州来定义它的时间。我不知道，但我想今天他们（官方或实际上）将时间定义为与 UTC 而不是 GMT 的偏移量。两者之间的差异始终小于一秒，因此对于许多用途而言，您无需关心。中部标准时间（例如 America/Chicago）的偏移量为 -6，山区夏令时也是如此（例如 America/Denver）。另一方面，偏移量 -6 并不一定意味着在美国的时间。当然，加拿大和墨西哥的部分地区也使用它，还有加拉帕戈斯群岛和复活节岛。
- 我认为您的示例时间不完全正确，但是，2018 年 1 月 2 日 00:00 UTC 与 2018 年 1 月 1 日在芝加哥 18:00 的时间点相同，其他冬季UTC-6（即北半球冬季）的地方。
进一步阅读：
- Systems of Time.
- Current Millis 对 UTC 与 GMT.
进行简单和复杂的比较
❌ 既不正确也没有用。
✅ 相反， 正确总结了技术差异——有关详细信息，请点击维基百科中详细页面的链接。
对于构建面向业务的应用程序的程序员来说，结果是 UTC 是新的 GMT。您可以互换使用这些术语，差异实际上不到一秒。因此，对于大多数应用程序的所有实际用途而言，根本没有区别。
这里有一些更实用的建议和代码示例。
字符串
Say, I have UTC time as "02-01-2018 00:03" does that mean my US local time is "01-01-2018 18:00"?
第一部分是一个不好的例子，日期时间字符串缺少其偏移量或区域的指示符。
如果字符串指示特定时刻，则它必须指示 time zone (Continent/Region 格式化名称）and/or 与 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.time classes (see Tutorial) bundled with Java 8 and later, and its predecessor the Joda-Time project (also loosely ported from Java to .Net in the Noda Time 项目）。
在java.time中，一个时刻用三种方式表示。都具有 nanoseconds.
的分辨率
Instant
始终使用 UTC。从技术上讲，自 1970 年第一个时刻 (1970-01-01T00:00:00Z) 的纪元参考以来的纳秒计数。 OffsetDateTime
在 UTC 之前或之后一定小时-分钟-秒的上下文中带有时间的日期。ZonedDateTime
具有特定时区上下文中的时间的日期。
那么time zone and an offset-from-UTC有什么区别呢？为什么我们需要单独的 类？与 UTC 的偏移量只是几个小时-分钟-秒，三个数字，不多也不少。 更多 的时区。时区是特定地区的人们使用的偏移量的过去、现在和未来变化的历史。
有什么变化？政客的心血来潮或智慧所决定的变化。世界各地的政客都表现出偏爱更改其管辖范围内时区使用的偏移量。 Daylight Saving Time (DST) is one common pattern of changes, with its schedule often changed and the decision to enact or revert from DST sometimes changed. Other changes happen too, such as just in the last few years North Korea changing their clock by half-an-hour to sync with South Korea, Venezuela turning back their clock half-an-hour only to jump back forward less than a decade later, Turkey this year canceled the scheduled change from DST to standard time with little forewarning, and contemporary Russia 近年来进行了多次此类更改。
回到第 3 点中的示例，让我们看一些代码。
Say, I have UTC time as "02-01-2018 00:03" does that mean my US local time is "01-01-2018 18:00"?
您的示例字符串还有另一个问题。第一部分的 03 分钟被忽略了你的第二部分，这是一个明显的错字。我知道，因为那天美洲没有有效的时区调整，涉及 57 分钟的小数小时。
一刻也没有
首先，我们解析您输入的字符串。由于缺少任何区域或偏移指示符，我们必须使用 LocalDateTime 进行解析。名称 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 本身分配零时分秒的 UTC 偏移量上下文。我们应用 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 晚 6 小时的挂钟时间来查看这一刻。具有这种偏移量的一个时区是 America/Chicago。
以continent/region的格式指定proper time zone name，例如America/Montreal、Africa/Casablanca或Pacific/Auckland。切勿使用 CST、EST 或 IST 等 2-4 字母缩写，因为它们 不是 真实时区，未标准化，并且甚至不是唯一的（！）。
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 ) ;
看到这个code run live at IdeOne.com。
odt.toString(): 2018-01-02T00:03Z
zdt.toString(): 2018-01-01T18:03-06:00[America/Chicago]
同一时刻，不同的挂钟时间
这个odt和zdt都代表了同一时刻，时间轴上的同一点。唯一的区别是挂钟时间。
让我们举个例子，使用冰岛，他们的时区使用零小时-分钟-秒的UTC偏移量。因此区域 Atlantic/Reykjavik 的挂钟时间与 UTC 相同。至少目前他们的挂钟时间与 UTC 时间一致；在过去或将来可能会有所不同，这就是为什么说“UTC 是冰岛时区”是不正确的。不管怎样，我们的例子……假设 Reykjavík, Iceland 的某个人在午夜后 3 分钟挂在他们墙上的时钟上给美国的某个人打了 phone 电话。该美国人居住在使用芝加哥地区时区的地方。当被呼叫的人拿起他们的 phone 时，他们抬头看了看挂在墙上的时钟，发现时间刚过下午 6 点 (18:03)。同一时刻，不同的挂钟时间。
另外，挂在墙上的日历也不一样，在冰岛是“明天”，在美国大陆是“昨天”。同样的时刻，不同的日期！
关于java.time
java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
Joda-Time project, now in maintenance mode, advises migration to the java.time 类.
要了解更多信息，请参阅 Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310。
您可以直接与数据库交换 java.time 对象。使用 JDBC driver compliant with JDBC 4.2 或更高版本。不需要字符串，不需要 java.sql.* 类.
java.time类在哪里获取？
- Java SE 8, Java SE 9, Java SE 10, Java SE 11，以及后来的 - 标准 Java API 的一部分，带有捆绑实现。
- Java 9 添加了一些小功能和修复。
- Java SE 6 and Java SE 7
- 大多数 java.time 功能已向后移植到 ThreeTen-Backport 中的 Java 6 和 7。
- Android
- Android java.time 类.
捆绑实施的更高版本
- 对于早期的Android（<26），ThreeTenABP项目适应 ThreeTen-Backport（如上所述）。请参阅
。
ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
GMT 是在格林威治子午线计算的平均太阳时。 https://www.rmg.co.uk/discover/explore/greenwich-mean-time-gmt
UTC 是基于铯原子钟极其规律的“滴答声”。 https://en.wikipedia.org/wiki/Coordinated_Universal_Time
它们既基于同一时间也以相同的方式计算。恕我直言，https://currentmillis.com 上的措辞充其量是误导性的，如果不是完全错误的话。
我有一些关于时区的问题：
- 是否可以单独使用 UTC 捕获时间？
- UTC -6 和 GMT -6 是否相同，是否意味着它是美国当地时间？
- 比如说，我的 UTC 时间是“02-01-2018 00:03”，这是否意味着我的美国当地时间是“01-01-2018 18:00”？
我在维基百科和许多相关网站上搜索过，但没有找到相关的解释。
协调世界时和格林威治标准时间之间没有时差。
7:17 星期五上午，协调世界时 (UTC) 是
7:17 格林威治标准时间 (GMT) 星期五上午
主要区别：UTC 和 GMT 都是时间标准，在派生和使用方面有所不同。
The Difference Between GMT and UTC:
Greenwich Mean Time (GMT) is often interchanged or confused with Coordinated Universal Time (UTC). But GMT is a time zone and UTC is a time standard.
Although GMT and UTC share the same current time in practice, there is a basic difference between the two:
- GMT is a time zone officially used in some European and African countries. The time can be displayed using both the 24-hour format (0 - 24) or the 12-hour format (1 - 12 am/pm).
- UTC is not a time zone, but a time standard that is the basis for civil time and time zones worldwide. This means that no country or territory officially uses UTC as a local time.
天文学与原子钟
根据最初的定义，不同之处在于 GMT (also officially known as Universal Time (UT)，这可能会造成混淆）是基于天文观测，而 UTC 是基于原子钟。后来 GMT 至少被非正式地用来指代 UTC，这在某种程度上模糊了区别。
GMT代表格林威治标准时间，英国伦敦东部南岸Royal Observatory in Greenwich的平太阳时。当太阳位于格林威治正上方的最高点时，是格林尼治标准时间中午 12 点。除了：地球自转略微不均匀，所以中午 12 点被定义为年平均值，即太阳处于最高点时的平均值。在 GMT 中，永远不会有任何闰秒，因为地球的自转不会跳跃。
UTC, which stands for Coordinated Universal Time in English, is defined by atomic clocks, but is otherwise the same. In UTC a second always has the same length. Leap seconds 被插入到 UTC 中以防止 UTC 和 GMT 漂移分开。相比之下，在 GMT 中，秒数会根据需要延长，因此原则上它们的长度并不总是相同。
在大约 100 年的时间里，格林威治标准时间被用作定义世界各地时间的基础。由于当今世界大多基于原子钟来精确定义时间，因此习惯上以 UTC 来定义时间。
编辑：GMT 的本意如今有些无用，但三个字母组合似乎并没有消失。我认为它经常被使用而不考虑UTC是否真的有意，所以不要太相信上面给出的严格定义。
您的问题：
- 是的，可以单独使用 UTC 捕获时间。以 UTC 格式存储时间并使用 UTC 传输 date-time 信息通常被认为是好的做法。
- 我想这取决于美国的每个州来定义它的时间。我不知道，但我想今天他们（官方或实际上）将时间定义为与 UTC 而不是 GMT 的偏移量。两者之间的差异始终小于一秒，因此对于许多用途而言，您无需关心。中部标准时间（例如 America/Chicago）的偏移量为 -6，山区夏令时也是如此（例如 America/Denver）。另一方面，偏移量 -6 并不一定意味着在美国的时间。当然，加拿大和墨西哥的部分地区也使用它，还有加拉帕戈斯群岛和复活节岛。
- 我认为您的示例时间不完全正确，但是，2018 年 1 月 2 日 00:00 UTC 与 2018 年 1 月 1 日在芝加哥 18:00 的时间点相同，其他冬季UTC-6（即北半球冬季）的地方。
进一步阅读：
- Systems of Time.
- Current Millis 对 UTC 与 GMT. 进行简单和复杂的比较
❌
✅ 相反，
对于构建面向业务的应用程序的程序员来说，结果是 UTC 是新的 GMT。您可以互换使用这些术语，差异实际上不到一秒。因此，对于大多数应用程序的所有实际用途而言，根本没有区别。
这里有一些更实用的建议和代码示例。
字符串
Say, I have UTC time as "02-01-2018 00:03" does that mean my US local time is "01-01-2018 18:00"?
第一部分是一个不好的例子，日期时间字符串缺少其偏移量或区域的指示符。
如果字符串指示特定时刻，则它必须指示 time zone (Continent/Region 格式化名称）and/or 与 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.time classes (see Tutorial) bundled with Java 8 and later, and its predecessor the Joda-Time project (also loosely ported from Java to .Net in the Noda Time 项目）。
在java.time中，一个时刻用三种方式表示。都具有 nanoseconds.
的分辨率Instant
始终使用 UTC。从技术上讲，自 1970 年第一个时刻 (1970-01-01T00:00:00Z) 的纪元参考以来的纳秒计数。OffsetDateTime
在 UTC 之前或之后一定小时-分钟-秒的上下文中带有时间的日期。ZonedDateTime
具有特定时区上下文中的时间的日期。
那么time zone and an offset-from-UTC有什么区别呢？为什么我们需要单独的 类？与 UTC 的偏移量只是几个小时-分钟-秒，三个数字，不多也不少。 更多 的时区。时区是特定地区的人们使用的偏移量的过去、现在和未来变化的历史。
有什么变化？政客的心血来潮或智慧所决定的变化。世界各地的政客都表现出偏爱更改其管辖范围内时区使用的偏移量。 Daylight Saving Time (DST) is one common pattern of changes, with its schedule often changed and the decision to enact or revert from DST sometimes changed. Other changes happen too, such as just in the last few years North Korea changing their clock by half-an-hour to sync with South Korea, Venezuela turning back their clock half-an-hour only to jump back forward less than a decade later, Turkey this year canceled the scheduled change from DST to standard time with little forewarning, and contemporary Russia 近年来进行了多次此类更改。
回到第 3 点中的示例，让我们看一些代码。
Say, I have UTC time as "02-01-2018 00:03" does that mean my US local time is "01-01-2018 18:00"?
您的示例字符串还有另一个问题。第一部分的 03 分钟被忽略了你的第二部分，这是一个明显的错字。我知道，因为那天美洲没有有效的时区调整，涉及 57 分钟的小数小时。
一刻也没有
首先，我们解析您输入的字符串。由于缺少任何区域或偏移指示符，我们必须使用 LocalDateTime 进行解析。名称 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 本身分配零时分秒的 UTC 偏移量上下文。我们应用 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 晚 6 小时的挂钟时间来查看这一刻。具有这种偏移量的一个时区是 America/Chicago。
以continent/region的格式指定proper time zone name，例如America/Montreal、Africa/Casablanca或Pacific/Auckland。切勿使用 CST、EST 或 IST 等 2-4 字母缩写，因为它们 不是 真实时区，未标准化，并且甚至不是唯一的（！）。
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 ) ;
看到这个code run live at IdeOne.com。
odt.toString(): 2018-01-02T00:03Z
zdt.toString(): 2018-01-01T18:03-06:00[America/Chicago]
同一时刻，不同的挂钟时间
这个odt和zdt都代表了同一时刻，时间轴上的同一点。唯一的区别是挂钟时间。
让我们举个例子，使用冰岛，他们的时区使用零小时-分钟-秒的UTC偏移量。因此区域 Atlantic/Reykjavik 的挂钟时间与 UTC 相同。至少目前他们的挂钟时间与 UTC 时间一致；在过去或将来可能会有所不同，这就是为什么说“UTC 是冰岛时区”是不正确的。不管怎样，我们的例子……假设 Reykjavík, Iceland 的某个人在午夜后 3 分钟挂在他们墙上的时钟上给美国的某个人打了 phone 电话。该美国人居住在使用芝加哥地区时区的地方。当被呼叫的人拿起他们的 phone 时，他们抬头看了看挂在墙上的时钟，发现时间刚过下午 6 点 (18:03)。同一时刻，不同的挂钟时间。
另外，挂在墙上的日历也不一样，在冰岛是“明天”，在美国大陆是“昨天”。同样的时刻，不同的日期！
关于java.time
java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
Joda-Time project, now in maintenance mode, advises migration to the java.time 类.
要了解更多信息，请参阅 Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310。
您可以直接与数据库交换 java.time 对象。使用 JDBC driver compliant with JDBC 4.2 或更高版本。不需要字符串，不需要 java.sql.* 类.
java.time类在哪里获取？
- Java SE 8, Java SE 9, Java SE 10, Java SE 11，以及后来的 - 标准 Java API 的一部分，带有捆绑实现。
- Java 9 添加了一些小功能和修复。
- Java SE 6 and Java SE 7
- 大多数 java.time 功能已向后移植到 ThreeTen-Backport 中的 Java 6 和 7。
- Android
- Android java.time 类. 捆绑实施的更高版本
- 对于早期的Android（<26），ThreeTenABP项目适应 ThreeTen-Backport（如上所述）。请参阅
ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
GMT 是在格林威治子午线计算的平均太阳时。 https://www.rmg.co.uk/discover/explore/greenwich-mean-time-gmt
UTC 是基于铯原子钟极其规律的“滴答声”。 https://en.wikipedia.org/wiki/Coordinated_Universal_Time
它们既基于同一时间也以相同的方式计算。恕我直言，https://currentmillis.com 上的措辞充其量是误导性的，如果不是完全错误的话。