您好我对时区的疑问很少：
我在维基百科和许多相关网站上搜索过但未找到相关解释
答案 0 :(得分：11)
区别在于GMT（也称为Universal Time (UT)，可能令人困惑）基于天文观测，而UTC则基于原子钟。
GMT代表格林威治标准时间，即英国东伦敦南岸格林威治皇家天文台的平均太阳时。当太阳位于格林威治正上方的最高点时，格林威治标准时间中午12点。除了：地球略微不均匀地旋转，因此中午12被定义为年平均值，即太阳最高时的平均值，它的高潮。在GMT中，永远不会有任何闰秒，因为地球的旋转不会跳跃。
UTC，代表英语协调世界时，由atomic clocks定义，但在其他方面相同。在UTC中，第二个总是具有相同的长度。 Leap seconds以UTC格式插入，以防止UTC和GMT分开。相比之下，在GMT中，根据需要延长秒数，因此原则上它们并不总是具有相同的长度。
在100年的时间里，GMT被用作定义世界时间的基础。由于现在世界主要基于原子钟上时间的精确定义，因此习惯上将时间定义基于UTC。
对于你的问题：
进一步阅读：Systems of Time。
答案 1 :(得分：6)
协调世界时和格林威治标准时之间没有时差 星期五上午7:17，世界协调时间（UTC）是 格林威治标准时间（格林威治标准时间）周五上午7:17
主要区别： UTC和GMT都是时间标准，在推导和使用方面有所不同。
GMT和UTC之间的差异：
格林威治标准时间（GMT）经常互换或混淆 协调世界时（UTC）。但GMT是一个时区，UTC是一个 时间标准。
尽管GMT和UTC在实践中分享相同的当前时间，但仍有 两者之间的基本区别：
- GMT是一些欧洲和非洲国家正式使用的时区。时间可以使用24小时格式（0 - 24）或12小时格式（1 - 12 am / pm）显示。
- UTC不是时区，而是时间标准，是全球公民时间和时区的基础。这意味着没有国家或 领土正式使用UTC作为当地时间。
答案 2 :(得分：6)
accepted Answer既不正确也不有用。相反，the Answer by Ole V.V.正确地总结了技术差异-有关详细信息，请访问Wikipedia中详细页面的链接。
对于开发面向业务的应用程序的程序员而言，结果是 UTC是新的GMT 。您可以互换使用这些术语，而差异实际上不到一秒钟。因此，对于大多数应用程序而言，出于所有实际目的，完全没有区别。
这里有一些更实用的建议，以及代码示例。
说，我的UTC时间是“ 02-01-2018 00:03”，这表示我的美国当地时间是“ 01-01-2018 18:00”吗？
第一部分是一个不好的例子，日期时间字符串缺少其偏移量或区域的指示符。
如果字符串表示特定时刻，则必须以小时-分钟-秒数的形式指示time zone（Continent/Region格式的名称）和/或与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 time as "02-01-2018 00:03"最好表示为2018-01-02T00:03Z。
请非常注意，大多数编程语言，库和数据库对日期时间处理的支持都很差，通常是基于对日期时间问题的了解不足。处理日期时间令人惊讶地复杂且难以掌握。
我遇到的唯一一个不错的库是与Java 8和更高版本捆绑在一起的java.time类（请参阅Tutorial），以及它的前身Joda-Time项目（也从Java松散地移植到了。{@ 3}项目中的.Net）。
在 java.time 中，时刻用三种方式表示。全部的分辨率为Noda Time。
Instant OffsetDateTime 那么ZonedDateTime和time zone有什么区别？为什么我们需要单独的课程？与UTC的偏移量只是小时-分钟-秒的数目，三个数字，不多也不少。 很多中的时区。时区是特定区域的人们过去，现在和将来对偏移量的更改的历史记录。
有什么变化？由政客的异想天开或智慧决定的变化。世界各地的政客都表现出偏爱更改其辖区时区使用的偏移量。 offset-from-UTC是一种常见的更改模式，其时间表经常更改，有时制定或撤消DST的决定也会更改。其他变化也发生了，例如最近几年Daylight Saving Time (DST)将时钟更改了半小时以与韩国同步，North Korea将时钟恢复了半小时才跳回不到十年后的今天，Venezuela turning在几乎没有预警的情况下取消了从DST到标准时间的预定更改，而当代Turkey在最近几年进行了多次更改。
回到第3点的示例，让我们看一些代码。
说，我的UTC时间是“ 02-01-2018 00:03”，这表示我的美国当地时间是“ 01-01-2018 18:00”吗？
您的示例字符串还有另一个问题。第一部分中的03分钟被忽略，而第二部分是明显的错别字。我知道，因为在该日期，美洲没有生效的时区调整，涉及的时分是57分钟。
首先，我们解析您的输入字符串。缺少任何区域或偏移量指示符，我们必须使用LocalDateTime进行解析。名称LocalDateTime可能会引起误解，因为它确实表示特定的位置。它表示任何或所有地区。有关更多说明，请参见Russia。
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晚6个小时的挂钟时间来了解这一刻。具有这种偏移量的一个时区为America/Chicago。
以continent/region的格式指定What's the difference between Instant and LocalDateTime?，例如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 ) ;
odt.toString（）：2018-01-02T00：03Z
zdt.toString（）：2018-01-01T18：03-06：00 [美国/芝加哥]
此odt和zdt代表相同的同时时刻，时间轴上的相同点。唯一的区别是挂钟时间。
让我们举个例子，以冰岛为例，他们所在的时区使用距UTC零时分-秒-秒的偏移量。因此，区域Atlantic/Reykjavik的挂钟时间与UTC相同。至少目前，他们的挂钟时间与UTC匹配；在过去或将来可能有所不同，这就是为什么说“ UTC 是冰岛的时区”是不正确的。无论如何，我们的示例……说code run live at IdeOne.com中某个在午夜3分钟后挂在他们墙上的人打了一个美国电话。该美国人居住在使用芝加哥地区时区的地方。当被叫方拿起电话时，他们抬头瞥了墙上挂着的时钟，发现时间刚好是下午6点（18:03）。相同的时刻，不同的时钟时间。
此外，挂在墙上的日历也有所不同，因为在冰岛是“明天”，在美国大陆是“昨天”。同一时刻，不同的日期！
Reykjavík, Iceland框架已内置在Java 8及更高版本中。这些类取代了麻烦的旧java.time日期时间类，例如legacy，java.util.Date和Calendar。
目前位于SimpleDateFormat的Joda-Time项目建议迁移到maintenance mode类。
要了解更多信息，请参见java.time。并在Stack Overflow中搜索许多示例和说明。规格为Oracle Tutorial。
您可以直接与数据库交换 java.time 对象。使用符合JSR 310或更高版本的JDBC driver。不需要字符串，不需要java.sql.*类。
在哪里获取java.time类？
How to use ThreeTenABP…项目使用其他类扩展了java.time。该项目为将来可能在java.time中添加内容提供了一个试验场。您可能会在这里找到一些有用的类，例如ThreeTen-Extra，Interval，YearWeek和YearQuarter。
答案 3 :(得分：2)
GMT 是在格林威治子午线计算的平均太阳时。 https://www.rmg.co.uk/discover/explore/greenwich-mean-time-gmt
UTC 基于铯原子钟极其规律的“滴答”。 https://en.wikipedia.org/wiki/Coordinated_Universal_Time
它们既不是基于相同的时间也不是以相同的方式计算。恕我直言，https://currentmillis.com 上的措辞充其量具有误导性，如果不只是完全不正确的话。