不，我不是在说区域偏移——这些偏移在一年中可能会根据夏令时等因素而变化。我说的是IANA维护的实际时区。我知道ISO 8601不支持这些，对吗？
平台在做什么来支持像字符串表示一样在ISO8601中识别时区？我注意到最新的Java日期/时间库为此使用了扩展的ISO8601格式，例如2011-12-03T10:15:30+01:00[Europe/Paris]。(请参阅DateTimeFormatter API。)
是否有一些趋同的约定(例如与其他语言和平台)来扩展ISO 8601以支持时区指定？
更新：
现在有一个IETF提案草案，用方括号中的时区标识符扩展RFC3339，其中包括：https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
原始答案：
我知道ISO 8601不支持这些，对吗？
正确。ISO-8601不涉及时区标识符。IANA/Olson TZ名称不是"；标准"；。它们只是我们拥有的最可靠的东西。(有些人可能认为它们是事实上的标准。)
平台正在做什么来支持这一点？
到底支持什么？你问题的这一部分不清楚。如果你想支持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/Paris2011-12-03T10:15:30+01:00 - Europe/Paris2011-12-03T10:15:30+01:00/Europe/Paris2011-12-03T10:15:30+01:00|Europe/Paris2011-12-03T10:15:30 Europe/Paris (+01)(这是Noda Time中的默认值)
如果您正在寻找一种以标准化方式在API中包含ZonedDateTime或类似数据的方法，我个人建议您在单独的字段中传递时区名称。这样，数据的每一部分都尽可能好
{
"timestamp": "2011-12-03T10:15:30+01:00",
"timezone": "Europe/Paris"
}
马特·约翰逊的回答很准确。我只想补充一些想法。
时区与utc的偏移
与UTC的偏移量仅为UTC前/后的小时、分钟和秒数。单独来看，这确实将日期时间变成了时间线上的特定时刻。但它的信息量远不如包括官方时区名称。
虽然还没有包含时区名称的标准，但我确实希望其他人效仿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)。世界各地的政治家都喜欢调整时区，甚至重新定义时区。因此，这些规则经常发生变化。将时区视为随时间推移的偏移量的集合，历史上的许多时间段中，每个时间段都有特定的偏移量在该特定区域使用。
您可以将时区视为UTC值偏移量的集合。在America/Los_Angeles中，今年的一部分时间比UTC晚8小时，今年的部分时间将比UTC晚7小时。这使得收集的2个数据点成为该时区的一部分。
另一个例子是，在前几年，土耳其每年有一部分时间比UTC提前2小时，还有一部分时间提前3小时。2016年，这一规定改为无限期提前3小时。因此，在时区Europe/Istanbul中有多个数据点。
只使用utc
就我个人而言，我认为即使使用2011-12-03T10:15:30+01:00这样的值也没有多大价值。如果没有时区，您还不如单独使用UTC。在这种情况下，2011-12-03T09:15:30Z(上午9点而不是上午10点)。
通常，最佳做法是在存储和交换日期-时间值时使用UTC将UTC视为唯一真实时间，分区或偏移值只是变化。