etc/GMT与UTC或GMT不是严格意义上的一回事。仅当偏移量为 0 时，它们才表示相同的时间时刻。在所有其他情况下，它们都是完全不同的。

苹果在这里解释了这个名称。

直接从链接中引用一个示例：

我们在区域名称和输出缩写中使用 POSIX 样式的符号，即使这与许多人的期望相反。POSIX在格林威治以西有积极的迹象，但许多人预计格林威治以东有积极的迹象。例如，TZ='Etc/GMT+4'使用缩写“GMT+4”，对应于 UTC 后 4 小时（即格林威治以西），尽管许多人预计它表示比 UTC 早 4 小时（即格林威治以东）。

偏移量与区域

理解：

• 与 UTC 的偏移量只是小时-分钟-秒数，早于 UTC 的基线或晚于 UTC。
• 时区远不止于此。时区是特定地区人民使用的偏移量的过去、现在和将来更改的历史记录。

正数与负数

各行各业的不同协议在编号上有所不同，一些协议认为UTC之前的偏移量是正数，而另一些协议则使用负数。对称地，有些人认为UTC后面的偏移量为负，而另一些人则使用正。

在我见过的大多数现代协议中，例如ISO 8601，UTC之前的偏移量（朝东）为正，而UTC（朝西）之后的偏移量为负。因此，美洲区域使用的偏移量具有负数，例如具有 或 现在的偏移量（由于夏令时 （DST） 而在一年中有所不同）。America/Los_Angeles-07:00-08:00

我建议你学会把这种方式（UTC的右边是正的，UTC的左边是负的）看作是主流，相反，这是一个小小的令人讨厌的变化。

时区名称的格式通常为 ，如 、、、和 。请参阅维基百科上的此列表（可能不是最新的）。有一些例外。这些名称带有相反的加/减约定：Continent/RegionAmerica/EdmontonEurope/ParisAfrica/TunisAsia/KolkataPacific/AucklandEtc/GMT…

• Etc/GMT+1 = -01:00偏移量 = 比 UTC 晚一小时
• Etc/GMT+12 = -12:00偏移量 = 比 UTC 晚 12 小时

...和。。。

• Etc/GMT-1 = +01:00偏移量 = 比 UTC 早一小时
• Etc/GMT-12 = +12:00偏移量 = 比 UTC 早 12 小时

混乱？欢迎来到日期时间处理的古怪世界。从这里开始，它只会变得更加奇怪。

要点：

• 了解那些发布数据的人的含义和意图。切勿假定输入字符串的含义。
• 仅对所有日期时间工作使用 java.time 类。永远不要使用可怕的遗留类、、、等。java.util.DateCalendarSimpleDateFormat

幸运的是，java.time类可以帮助你度过这个混乱。请参阅 Ole V.V. 使用该类的正确答案。ZoneId

您的问题

苹果使用Etc/GMT时区背后的基本原理

它们表示零的偏移量，即 UTC 本身。该字符串是一个规范标签，表示从 UTC 偏移量为零小时-分钟-秒。Etc/GMT

通常在日期时间字符串末尾看到的字母（发音为“Zulu”）意味着同样的事情，即零的偏移量。Z

Etc/GMT时区到底是什么？

该字符串是一个时区的名称，该时区曾经只有一个与 UTC 的偏移量，即零小时-分-秒的偏移量。Etc/GMT

大多数其他时区（如或）在历史记录中的偏移量各不相同。例如，在摩洛哥的非洲/卡萨布兰卡地区，政客们去年决定，他们现在将全年永久停留在DST上，而不是每年两次切换一小时的标准时间和DST。我笑着说“永久”，因为这实际上意味着“直到政客们再次改变主意”。世界各地的政治家都表现出以惊人的频率重新定义时区的倾向。Europe/BerlinAfrica/Casablanca

Java SDK 是否了解此时区？

是的。请参阅Ole V.V.的答案：ZoneId.of( "Etc/GMT" )

还是我必须使用其他第三方库，如Joda-Time？

仅供参考，Joda-Time项目现在处于维护模式，建议迁移到java.time类。请参阅 Oracle 的教程。

您应该使用 java.time 类来处理所有日期时间。