java 在 ISO 8601 中识别时区

Identifying time zones in ISO 8601

提问by Garret Wilson

No, I'm not talking about zone offsets --- those can vary during the year for a region based on e.g. DST. I'm talking about the actual time zones maintained by IANA. I understand these are notsupported by ISO 8601, correct?

不，我不是在谈论区域偏移量 --- 基于 DST 等，区域偏移量在一年中可能会有所不同。我说的是 IANA 维护的实际时区。我知道ISO 8601不支持这些，对吗？

What are platforms doing to support identifying time zones in ISO 8601-like string representations? I notice that the latest Java date/time library is using an extended ISO 8601 format for this, e.g. 2011-12-03T10:15:30+01:00[Europe/Paris]. (See DateTimeFormatter API.)

平台如何支持在类似 ISO 8601 的字符串表示中识别时区？我注意到最新的 Java 日期/时间库为此使用了扩展的 ISO 8601 格式，例如2011-12-03T10:15:30+01:00[Europe/Paris]. （请参阅DateTimeFormatter API。）

Is there some converging convention (e.g. with other languages and platforms) for extending ISO 8601 to support time zone designation?

是否有一些收敛约定（例如与其他语言和平台）来扩展 ISO 8601 以支持时区指定？

回答by Matt Johnson-Pint

I understand these are not supported by ISO 8601, correct?

我知道 ISO 8601 不支持这些，对吗？

Correct. ISO-8601 does not concern itself with time zone identifiers. IANA/Olson TZ names are not a "standard". They are just the most reliable thing we have. (Some may consider them the de factostandard.)

正确的。ISO-8601 不关心时区标识符。IANA/Olson TZ 名称不是“标准”。它们只是我们拥有的最可靠的东西。（有些人可能认为它们是事实上的标准。）

What are platforms doing to support this?

平台正在做什么来支持这一点？

Support what exactly? This part of your question is unclear. If you mean to support IANA time zones, well that's all over the place. Some platforms have them built-in, and some rely on libraries. If you mean to support a string representation of an ISO-8601 date-time-offset + time zone ID, some platforms have this and some do not. You'll have to be more specific if you want to know more.

具体支持什么？你的这部分问题不清楚。如果您的意思是支持 IANA 时区，那么一切都是如此。有些平台内置了它们，有些则依赖于库。如果您打算支持 ISO-8601 日期时间偏移 + 时区 ID 的字符串表示形式，则某些平台具有此功能，而有些平台则没有。如果您想了解更多信息，则必须更具体。

I notice that the latest Java date/time library is using an extended ISO 8601 format for this, e.g. 2011-12-03T10:15:30+01:00[Europe/Paris]. (See DateTimeFormatter API.)

我注意到最新的 Java 日期/时间库为此使用了扩展的 ISO 8601 格式，例如 2011-12-03T10:15:30+01:00[Europe/Paris]。（请参阅 DateTimeFormatter API。）

I think you are talking about DateTimeFormatter.ISO_ZONED_DATE_TIME. The docs say specifically:

我想你在谈论DateTimeFormatter.ISO_ZONED_DATE_TIME. 文档特别说明：

The ISO-likedate-time formatter...

...extends the ISO-8601 extended offset date-time format to add the time-zone. The section in square brackets is not part of the ISO-8601 standard.

该ISO-像日期-时间格式...

...扩展 ISO-8601 扩展偏移日期时间格式以添加时区。方括号中的部分不是 ISO-8601 标准的一部分。

So this is Java's specific format, not a standard.

所以这是Java的特定格式，而不是标准。

Is there some converging convention (e.g. with other languages and platforms) for extending ISO 8601 to support time zone designation?

是否有一些收敛约定（例如与其他语言和平台）来扩展 ISO 8601 以支持时区指定？

As far as I know, there is currently no standard that covers the combining of an ISO8601 timestamp and an IANA time zone identifier into a single format. One could represent it many different ways, including:

据我所知，目前还没有将 ISO8601 时间戳和 IANA 时区标识符组合成单一格式的标准。人们可以用多种不同的方式来表示它，包括：

• 2011-12-03T10:15:30+01:00[Europe/Paris](this is the default in Java 8)
• 2011-12-03T10:15:30+01:00(Europe/Paris)
• 2011-12-03T10:15:30+01:00 Europe/Paris
• 2011-12-03T10:15:30+01:00 - Europe/Paris
• 2011-12-03T10:15:30+01:00/Europe/Paris
• 2011-12-03T10:15:30+01:00|Europe/Paris
• 2011-12-03T10:15:30 Europe/Paris (+01)(this is the default in Noda Time)

• 2011-12-03T10:15:30+01:00[Europe/Paris]（这是 Java 8 中的默认设置）
• 2011-12-03T10:15:30+01:00(Europe/Paris)
• 2011-12-03T10:15:30+01:00 Europe/Paris
• 2011-12-03T10:15:30+01:00 - Europe/Paris
• 2011-12-03T10:15:30+01:00/Europe/Paris
• 2011-12-03T10:15:30+01:00|Europe/Paris
• 2011-12-03T10:15:30 Europe/Paris (+01)（这是野田时间的默认设置）

If what you're looking for is a way to include a ZonedDateTimeor similar data in an API in a standardized manner, my personal recommendation would be to pass the time zone name in a separate field. That way, each portion of data is as good as it can be. For example in JSON:

如果您正在寻找一种以ZonedDateTime标准化方式在 API 中包含一个或类似数据的方法，我个人的建议是在单独的字段中传递时区名称。这样，数据的每一部分都尽可能好。例如在 JSON 中：

{
  "timestamp": "2011-12-03T10:15:30+01:00",
  "timezone": "Europe/Paris"
}

回答by Basil Bourque

The Answer by Matt Johnsonis spot-on correct. I'll just add a few thoughts.

马特约翰逊的答案是正确的。我只是补充一些想法。

Time zone versus offset-from-UTC

时区与 UTC 偏移量

An offset-from-UTCis merely a number of hours, minutes, and seconds ahead/behind UTC. Alone, this does make a date-time into a specific moment on the timeline. But it is not nearly as informative as including the official time zone nameas well.

一个偏移从-UTC仅仅是若干小时，分钟和秒超前/落后UTC。单独，这确实使日期时间成为时间轴上的特定时刻。但它的信息量远不如包含官方时区名称。

While there is no standard yet for including the time zone name, I do hope others follow the lead of the java.time classes in appending in square brackets the name of the time zone. This format seems sensible to me as it would be simple to truncate the square-bracket portion to be backward-compatible with non-savvy software.

虽然目前还没有包含时区名称的标准，但我确实希望其他人遵循 java.time 类的做法，将时区名称附加在方括号中。这种格式对我来说似乎很明智，因为截断方括号部分以与非智能软件向后兼容会很简单。

For example:
2011-12-03T10:15:30+01:00[Europe/Paris]. If the data were only 2011-12-03T10:15:30+01:00, we would be able to identify the moment on the timeline, but would not be able to adjust other moments into the same frame of mind as we would not know what rules of adjustment to apply. Zones such as Europe/Zagreb, Africa/Brazzaville, Arctic/Longyearbyen, and Europe/Isle_of_Manall share the offset of +01:00, but they may well have other adjustments in force differing from those of Europe/Paris. So if you were to try to add three days to the value 2011-12-03T10:15:30+01:00, you really cannot faithfully compute the result because you do not know what adjustments may need to apply such as DST cutovers that may be occurring during those three days.

例如：
2011-12-03T10:15:30+01:00[Europe/Paris]。如果数据只有2011-12-03T10:15:30+01:00，我们将能够识别时间轴上的时刻，但无法将其他时刻调整到同一思维框架中，因为我们不知道要应用哪些调整规则。区域，如Europe/Zagreb，Africa/Brazzaville，Arctic/Longyearbyen，并且Europe/Isle_of_Man都有着偏差的+01:00，但他们很可能在力等调整从这些不同的Europe/Paris。因此，如果您尝试将 3 天添加到该值2011-12-03T10:15:30+01:00，您确实无法忠实地计算结果，因为您不知道可能需要应用哪些调整，例如在这 3 天内可能发生的 DST 转换。

A time zone defines the set of rules for handling anomalies such as Daylight Saving Time (DST). Politicians around the world enjoy making adjustments to their time zones, or even re-defining them. So these rules change frequently. Think of a time zone as a collection of offsets over time, many periods of time in history wherein each period had a particular offset in use in that particular region.

时区定义了一组处理异常的规则，例如夏令时 (DST)。世界各地的家都喜欢调整时区，甚至重新定义时区。所以这些规则经常改变。将时区视为随时间推移的偏移量的集合，历史上有许多时间段，其中每个时间段在该特定区域使用特定的偏移量。

You can think of a time zone as a collection of offset-from-UTC values. In America/Los_Angelespart of this year is 8 hours behind UTC, and part of the year will be 7 hours behind UTC. That makes 2 points of data collected as part of that time zone.

您可以将时区视为 UTC 偏移值的集合。今年的America/Los_Angeles部分时间比 UTC 晚 8 小时，而今年的部分时间将比 UTC 晚 7 小时。这使得作为该时区的一部分收集的 2 个数据点。

Another example, in previous years, Turkey spent part of each year 2 hours ahead of UTC and part of each year 3 hours ahead. In 2016, that changed to indefinitely staying 3 hours ahead. So, multiple points of data in the time zone Europe/Istanbul.

另一个例子，在前几年，土耳其每年有一部分时间比 UTC 提前 2 小时，每年有一部分时间提前 3 小时。2016 年，这变为无限期地提前 3 小时。因此，时区中的多个数据点Europe/Istanbul。

Just use UTC

只需使用 UTC

Personally I do not see much value in even using values such as 2011-12-03T10:15:30+01:00. Without a time zone, you might just as well use UTC alone. In this case, 2011-12-03T09:15:30Z(9 AM instead of 10 AM).

就我个人而言，即使使用诸如2011-12-03T10:15:30+01:00. 如果没有时区，您不妨单独使用 UTC。在这种情况下，2011-12-03T09:15:30Z（上午 9 点而不是上午 10 点）。

Generally the best practice is to use UTC when storing and exchanging date-time values. Think of UTC as the One-True-Time, with zoned or offset values being mere variations.

通常，最佳做法是在存储和交换日期时间值时使用 UTC。将 UTC 视为 One-True-Time，分区或偏移值仅仅是变化。