Java ISO 8601中的时区识别

不，我不是说区域偏移量——这些偏移量在一年中根据DST等区域可能会有所不同。我说的是实际情况。我知道ISO 8601不支持这些，对吗

平台如何支持在ISO 8601中识别时区，比如字符串表示？我注意到最新的Java日期/时间库为此使用了扩展的ISO 8601格式，例如

2011-12-03T10:15:30+01:00[欧洲/巴黎]

。（见附件。）

在扩展ISO 8601以支持时区指定方面是否有一些趋同的约定（例如与其他语言和平台的约定）？

更新： 现在有一份IETF提案草案，将RFC3339扩展为方括号内的时区标识符，其中包括：

原始答复： 我知道ISO 8601不支持这些，对吗

对。ISO-8601不涉及时区标识符。IANA/Olson TZ名称不是“标准”。它们是我们拥有的最可靠的东西。（有些人可能认为它们是事实上的标准。） 平台正在做什么来支持这一点

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

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

我想你在说什么。文件明确指出：

ISO-类似于日期时间格式化程序

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

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

在扩展ISO 8601以支持时区指定方面是否有一些趋同的约定（例如与其他语言和平台）

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

• 2011-12-03T10:15:30+01:00[欧洲/巴黎]

  （这是Java 8中的默认值）

• 2011-12-03T10:15:30+01:00（欧洲/巴黎）

• 2011-12-03T10:15:30+01:00欧洲/巴黎

• 2011-12-03T10:15:30+01:00-欧洲/巴黎

• 2011-12-03T10:15:30+01:00/欧洲/巴黎

• 2011-12-03T10:15:30+01:00 |欧洲/巴黎

• 2011-12-03T10:15:30欧洲/巴黎（+01）

  （这是野田时间的默认值）

如果您正在寻找一种方法，以标准化的方式在API中包含

ZoneDateTime

或类似数据，我个人的建议是在单独的字段中传递时区名称。这样，数据的每一部分都尽可能好。例如，在JSON中：

{
“时间戳”：“2011-12-03T10:15:30+01:00”，
“时区”：“欧洲/巴黎”
}

位置正确。我只想补充一些想法

时区与UTC的偏移量 一个时间仅仅是一个小时、分钟和秒数。仅此一项，就可以将日期时间转换为时间线上的特定时刻。但是，它的信息量远不如将这些信息也包括在内

虽然还没有包含时区名称的标准，但我确实希望其他人效仿java.time类，在方括号中添加时区名称。对我来说，这种格式似乎是合理的，因为截断方括号部分可以很简单地向后兼容非精明的软件

例如：

2011-12-03T10:15:30+01:00[欧洲/巴黎]

。如果数据仅为

2011-12-03T10:15:30+01:00

，我们将能够识别时间线上的时刻，但无法将其他时刻调整到相同的心态，因为我们不知道要应用什么调整规则。诸如

欧洲/萨格勒布

，

非洲/布拉柴维尔

，

北极/朗伊尔拜恩

，以及

欧洲/马恩岛

等区域都有

+01:00

的偏移量，但它们可能有与

欧洲/巴黎

不同的其他有效调整。因此，如果您试图在值

2011-12-03T10:15:30+01:00

中添加三天，您确实无法忠实地计算结果，因为您不知道可能需要应用哪些调整，例如在这三天内可能发生的DST切换

时区定义了处理异常的一组规则，例如。全世界的政治家都喜欢调整时区，甚至重新定义时区。因此，这些规则经常变化。将时区视为一段时间内偏移量的集合，历史上的许多时段中，每个时段都有一个特定区域中使用的特定偏移量

您可以将时区视为UTC值偏移量的集合。今年部分时间落后UTC 8小时，部分时间落后UTC 7小时。这使得作为时区一部分收集的数据有2个点

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

只需使用UTC 就我个人而言，即使使用

2011-12-03T10:15:30+01:00

这样的值，我也看不出有多大价值。如果没有时区，您也可以单独使用UTC。在这种情况下，

2011-12-03T09:15:30Z

（上午9点而不是上午10点）

一般来说，bes