モジュール java.base
パッケージ java.time

クラスZoneId

java.lang.Object
java.time.ZoneId
すべての実装されたインタフェース:
Serializable
直系の既知のサブクラス:
ZoneOffset
public abstract sealed class ZoneId extends Object implements Serializable permits ZoneOffset (not exhaustive)
タイムゾーンID(ヨーロッパ/パリなど)。

ZoneIdは、InstantおよびLocalDateTimeの間の変換に使用するルールを識別するために使用されます。 タイプの異なる2つのIDがあります。

  • 固定オフセット - UTC/グリニッジからの完全に解決されたオフセット、すべてのローカル日付/時間に同じオフセットを使用
  • 地理的地域 - UTC/グリニッジからのオフセットを見つけるために特定のルール・セットが適用される地域
ほとんどの固定オフセットはZoneOffsetで表されます。 ZoneId上でnormalized()を呼び出すことで、固定オフセットIDがZoneOffsetとして表現されることが保証されます。

実際のルールは、オフセットがいつ、どのように変化するかを記述し、ZoneRulesによって定義されます。 このクラスは単純に、基礎となるルールを取得するために使用されるIDです。 この方法は、ルールが政府によって定義されていて頻繁に変わるけれども、IDは固定しているために採用されます。

この違いには他の影響があります。 ZoneIdを直列化するとIDのみが送信されますが、ルールを直列化するとデータ・セット全体が送信されます。 同様に、2つのIDの比較はIDのみを調べますが、2つのルールの比較はデータ・セット全体を調べます。

タイムゾーンID

IDはシステム内で一意です。 3つのタイプのIDがあります。

もっとも単純なタイプのIDはZoneOffsetからのものです。 これは、Zと、+または-で始まるIDで構成されます。

次のタイプのIDは、なんらかの形式の接頭辞を持つ、オフセット・スタイルID(「GMT+2」や「UTC+01:00」など)です。 認識される接頭辞は、UTC、GMTおよびUTです。 オフセットは接尾辞で、作成時に正規化されます。 これらのIDは、normalized()を使用してZoneOffsetに正規化できます。

3番目のタイプのIDは、地域ベースIDです。 地域ベースIDは2つ以上の文字で構成される必要があり、UTC、GMTまたはUT+または-で始まってはいけません。 地域ベースIDは構成で定義されます。ZoneRulesProviderを参照してください。 構成は、IDから基礎となるZoneRulesへのルックアップを提供することを主眼としています。

タイムゾーン・ルールは政府によって定義され、頻繁に変わります。 タイムゾーン変更をモニターしてそれらを照合する組織(グループと呼ばれる)がいくつかあります。 デフォルトグループは、IANAタイムゾーン・データベース(TZDB)です。 他の組織には、IATA (航空業界団体)とMicrosoftが含まれます。

各グループは、提供する地域IDのために独自フォーマットを定義します。 TZDBグループは、Europe/LondonやAmerica/New_YorkなどのIDを定義します。 TZDB IDは、他のグループより優先されます。

重複を避けるために、TZDB以外のグループで提供されるすべてのIDにはグループ名が含まれるようにすることが強く推奨されています。 たとえば、IATA航空タイムゾーン地域IDは、一般的には3文字の空港コードと同じです。 しかし、ユトレヒトの空港はコード「UTC」を持ち、これは明らかに重複です。 TZDB以外のグループからの地域IDに推奨されるフォーマットは、グループ~地域です。 つまり、IATAデータが定義されている場合は、ユトレヒト空港はIATA~UTCになります。

直列化

このクラスは直列化でき、文字列ゾーンIDを外部形式で格納します。 ZoneOffsetサブクラスは、UTC/グリニッジからのオフセットのみを格納する、専用フォーマットを使用します。

ZoneIdは、IDが不明であるJava Runtimeで直列化復元できます。 たとえば、サーバー側Java Runtimeが新しいゾーンIDで更新されたけれども、クライアント側Java Runtimeが更新されていない場合です。 この場合、ZoneIdオブジェクトは存在し、getId、equals、hashCode、toString、getDisplayNameおよびnormalizedを使用して照会できます。 しかし、getRulesへの呼び出しはZoneRulesExceptionで失敗します。 この方法は、タイムゾーン情報が不完全なJava Runtimeで、ZonedDateTimeはロードおよび照会されても変更されないように設計されています。

これはvalue-basedクラスです。プログラマは、equalのインスタンスを交換可能として扱い、同期にインスタンスを使用しないようにする必要があります。そうしないと、予期しない動作が発生する可能性があります。 たとえば、将来のリリースでは、同期が失敗する可能性があります。 比較する場合は、equalsメソッドを使用することをお薦めします。

実装要件:
この抽象的な封印クラスでは、2つの実装が許可され、どちらも不変でスレッド・セーフです。 一方の実装は地域ベースIDをモデル化し、もう一方はオフセット・ベースIDをモデル化するZoneOffsetです。 違いは直列化で現れます。
シール済クラス階層グラフ:
ZoneIdのシール済クラス階層グラフZoneIdのシール済クラス階層グラフ
導入されたバージョン:
1.8
関連項目: