不，我不是在谈论区域偏移 - 这些区域在一年中可能会因区域偏差而异。 DST。我正在谈论实际的time zones maintained by IANA。我知道ISO 8601支持不，对吗？
在支持ISO 8601的字符串表示中识别时区的平台是做什么的？我注意到最新的Java日期/时间库正在使用扩展的ISO 8601格式，例如2011-12-03T10:15:30+01:00[Europe/Paris]。 （见DateTimeFormatter API。）
是否有一些融合惯例（例如与其他语言和平台一起）用于扩展ISO 8601以支持时区指定？
答案 0 :(得分：17)
我知道ISO 8601不支持这些，对吗？
正确。 ISO-8601不涉及时区标识符。 IANA / Olson TZ名称不是＆＃34;标准＆＃34;。它们只是我们拥有的最可靠的东西。 （有些人可能认为它们是事实上的标准。）
平台在做什么来支持这个？
支持究竟是什么？这部分问题尚不清楚。如果您的意思是支持IANA时区，那么整个地方都是如此。有些平台内置了它们，有些平台依赖于库。如果你的意思是支持ISO-8601日期时间偏移+时区ID的字符串表示，有些平台有这个，有些则没有。如果你想了解更多信息，你必须更加具体。
我注意到最新的Java日期/时间库正在使用扩展的ISO 8601格式，例如： 2011-12-03T10：15：30 + 01：00 [欧洲/巴黎]。 （请参阅DateTimeFormatter API。）
我认为你在谈论DateTimeFormatter.ISO_ZONED_DATE_TIME。文档特别说：
ISO- 喜欢日期时间格式化程序......
...扩展ISO-8601扩展偏移日期时间格式以添加时区。方括号中的部分不是ISO-8601标准的一部分。
所以这是Java的特定格式，而不是标准格式。
是否有一些融合惯例（例如与其他语言和平台一起）用于扩展ISO 8601以支持时区指定？
据我所知，目前还没有标准涵盖将ISO8601时间戳和IANA时区标识符合并为单一格式。人们可以用许多不同的方式来代表它，包括：
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)（这是Noda Time中的默认值）如果您正在寻找的是一种以标准化方式在API中包含ZonedDateTime或类似数据的方法，我的个人建议是在单独的字段中传递时区名称。这样，每个数据部分都尽可能好。例如在JSON中：
{
"timestamp": "2011-12-03T10:15:30+01:00",
"timezone": "Europe/Paris"
}
答案 1 :(得分：11)
Answer by Matt Johnson是正确无误的。我只想补充一些想法。
offset-from-UTC只是前后几个小时，分钟和秒UTC。单独，这确实将日期时间转换为时间轴上的特定时刻。但它并不像包括official time zone name那样具有信息性。
虽然还没有标准来包含时区名称，但我希望其他人跟随java.time类的引导，在方括号中附加时区的名称。这种格式对我来说似乎很明智，因为将方括号部分截断为与非精明软件向后兼容会很简单。
例如：
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。因此，如果您尝试将三天添加到值2011-12-03T10:15:30+01:00，您实际上无法忠实地计算结果，因为您不知道可能需要应用哪些调整，例如可能在这三天内发生的DST切换。
时区定义了处理Daylight Saving Time (DST)等异常的规则集。世界各地的政治家们喜欢调整他们的时区，甚至重新定义他们的时区。所以这些规则经常变化。将时区视为随时间变化的偏移集合，历史上的许多时间段，其中每个时段在该特定区域中具有特定的偏移量。
您可以将时区视为从UTC值偏移的集合。今年America/Los_Angeles部分比UTC晚8小时，部分时间比UTC晚7小时。这使得2个数据点被收集作为该时区的一部分。
另一个例子，在过去几年中，土耳其每年的部分时间比UTC早2小时，而每年的部分时间则提前3小时。 2016年，改为无限期地提前3小时。因此，时区Europe/Istanbul中的多个数据点。
就我个人而言，即使使用2011-12-03T10:15:30+01:00等值，我也看不到多少价值。没有时区，您也可以单独使用UTC。在这种情况下，2011-12-03T09:15:30Z（上午9点而不是上午10点）。
通常，最佳做法是在存储和交换日期时间值时使用UTC。 将UTC视为One-True-Time ，区域划分或偏移值仅为变化。