ISO 8601でのタイムゾーンの特定
いいえ、ゾーンオフセットについては言及していません。これらは、たとえば、 DST。実際の IANAが管理するタイムゾーン について話しています。私はこれらがISO 8601でサポートされているnotであることを理解していますか？
ISO 8601のような文字列表現でタイムゾーンの識別をサポートするために、プラットフォームは何をしていますか？最新のJava date/timeライブラリは、これに拡張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 [Europe/Paris]。 DateTimeFormatter APIを参照してください。）
_DateTimeFormatter.ISO_ZONED_DATE_TIME_ について話していると思います。ドキュメントは具体的に言う：
ISO-like日時フォーマッター...
... 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)（これは野田時間のデフォルトです）
探しているのがZonedDateTimeまたは同様のデータを標準化された方法でAPIに含める方法である場合、個人的な推奨事項は、別のフィールドにタイムゾーン名を渡すことです。そうすれば、データの各部分は可能な限り良好です。 JSONの例：
_{
"timestamp": "2011-12-03T10:15:30+01:00",
"timezone": "Europe/Paris"
}
_Matt Johnsonによる回答 は正解です。いくつかの考えを追加します。
タイムゾーンとUTCからのオフセット
offset-from-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に3日間を追加しようとした場合、その3日間に発生する可能性のあるDSTカットオーバーなど、どの調整を適用する必要があるかわからないため、結果を忠実に計算できません。
タイムゾーンは、 夏時間（DST） などの異常を処理するための一連のルールを定義します。世界中の政治家は、タイムゾーンを調整したり、再定義したりすることを楽しんでいます。したがって、これらのルールは頻繁に変更されます。タイムゾーンは、時間の経過に伴うオフセットのコレクションと考えてください。これは、各期間が特定の地域で使用されている特定のオフセットがあった、履歴内の多くの期間です。
タイムゾーンは、UTCからのオフセット値のコレクションと考えることができます。 America/Los_Angeles では、今年の一部はUTCから8時間遅れており、今年の一部はUTCから7時間遅れています。これにより、そのタイムゾーンの一部として2ポイントのデータが収集されます。
別の例として、過去数年間、トルコは毎年の一部をUTCより2時間早く、毎年の一部をUTCより3時間早く過ごしました。 2016年、それは無期限に3時間先を行くことに変わりました。したがって、タイムゾーンの複数のデータポイント Europe/Istanbul 。
UTCを使用するだけ
個人的には、2011-12-03T10:15:30+01:00などの値を使用してもあまり価値がありません。タイムゾーンがなければ、UTCのみを使用することもできます。この場合、2011-12-03T09:15:30Z（午前10時ではなく午前9時）。
一般に、ベストプラクティスは、日時の値を格納および交換するときにUTCを使用することです。 UTCをOne-True-Timeと考えてください。ゾーン値またはオフセット値は単なるバリエーションです。