不，我不是在談論區域偏移量---這些偏移量可能會在一年中因某個地區而異。 DST。我在談論實際的time zones maintained by IANA。我明白這些是由ISO 8601支持的而不是，對嗎？識別ISO 8601中的時區
什麼是平臺在ISO 8601類似的字符串表示中支持識別時區？我注意到最新的Java日期/時間庫爲此使用了擴展的ISO 8601格式。 2011-12-03T10:15:30+01:00[Europe/Paris]。 （請參閱DateTimeFormatter API。）
是否存在一些用於擴展ISO 8601以支持時區指定的聚合約定（例如，與其他語言和平臺）？
我明白這些不受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) （這是N中的默認值oda時間）如果您正在尋找的是以標準方式在API中包含ZonedDateTime或類似數據的方式，我個人的建議是將時區名稱傳遞到單獨的字段中。這樣，數據的每個部分都是儘可能好的。例如在JSON中：
{
"timestamp": "2011-12-03T10:15:30+01:00",
"timezone": "Europe/Paris"
}
另外，有趣的是，頂部的[Java ZonedDateTime文檔]（https://docs.oracle.com/javase/8/docs/api/java/time/ZonedDateTime.html）使用了帶空格分隔符的格式的括號內。 ;） –
「支持到底是什麼？你的問題的這一部分不清楚。」那麼，我認爲我把它放在標題中......但是很公平 - 我已經更新了這個問題。 「如果您的意思是支持ISO-8601日期 - 時間偏移+時區ID的字符串表示形式，則某些平臺具有此功能，有些則不具備此功能。」那是我問的問題。其他平臺在做什麼？我希望有人能給我一些其他的例子，所以我可以知道Java是否是單獨的，或者它是否正在遵循一些趨同的趨勢。 –
「人們可以用許多不同的方式來表達......」的確，@MattJohnson，我可以整天坐在這裏發明數百種表示時區的可能變化形式。問題在於是否存在一些新興的共識，甚至是Java方法以外的其他「在野外」使用的例子。 –
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視爲一次真實時間，分區或偏移值僅僅是變化。
儘可能同意使用UTC的建議。但是，某些用例很尷尬：如果邏輯必須引用過去或未來的任意事件，而唯一的時間信息位於本地區域中，則UTC轉換不明顯。 （例如，紐約證券交易所將在三月的第二個星期二的什麼時間，10年後開放？在當地時間，ET很可能是上午9:30，但UTC取決於DST轉換 - 甚至這取決於規則在此之前不會改變）。因此，在這種情況下，最好有一個用於表示本地分區時間的標準。 – Sumitsu
@Sumitsu我完全同意，100％。我強調相反的立場，因爲我發現程序員傾向於：（a）讓自己堅持轉換進出自己的狹隘時區，（b）認爲（祈禱）使用「本地」（未分區）日期時間值將以某種方式使他們不必處理時區問題。但正如你所說，LocalDateTime在很多情況下都是有用的，特別是像紐約證券交易所開盤這樣的應用程序，因爲政治家經常如此不經意地如此迅速地重新定義時區。例如，就在去年，土耳其決定停留在夏令時，只有幾個星期的警告。 –
只要TZ-offset允許收集*一些*客戶相對值。雖然不如TZ的名字其他用途強壯，它確實提供了一小步......主要是（在99％的情況下，在*時間的錄音*），允許一個「日」與時間截然不同，同時捕獲在「單個標量」內。 TZ-offset在TZ名稱上具有很好的屬性，因爲它是純粹映射到UTC的，雖然能夠*還*以這種'單一標量'形式捕獲TZ名稱將很好，以便將來改進處理：} – user2864740
第二個問題點使這個問題相當廣泛。 – chrylis
我讀[W3C說明]（https://www.w3.org/TR/NOTE-datetime）的方式似乎是正確的：ISO 8601支持區域偏移，但不支持具有可變偏移量的時區（通常爲時區夏季時間，這適用於許多IANA時區）。 –
@ OleV.V。您鏈接的W3C Note文檔僅僅是實際ISO 8601標準的簡要摘要。我建議閱讀[ISO 8601維基百科文章]（https://en.wikipedia.org/wiki/ISO_8601）和[星期日期]（https://en.wikipedia.org/wiki/ISO_week_date）上的優秀文章，以及也許是[標準草案]（https://duckduckgo.com/?q=ISO+8601+draft&t=osx&ia=web）（官方標準在付費牆後面）。 –