ZoneId Klasse

Definition

[Android.Runtime.Register("java/time/ZoneId", ApiSince=26, DoNotGenerateAcw=true)]
public abstract class ZoneId : Java.Lang.Object, IDisposable, Java.IO.ISerializable

[<Android.Runtime.Register("java/time/ZoneId", ApiSince=26, DoNotGenerateAcw=true)>]
type ZoneId = class
    inherit Object
    interface ISerializable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Vererbung

Object

JavaObject

Object

ZoneId

Abgeleitet

Java.Time.ZoneOffset

Attribute

RegisterAttribute

Implementiert

IJavaObject IJavaPeerable ISerializable IDisposable

Hinweise

Eine Zeitzonen-ID, z Europe/Paris. B. .

A ZoneId wird verwendet, um die Regeln zu identifizieren, die zum Konvertieren zwischen einem Instant und einem LocalDateTime. Es gibt zwei unterschiedliche Typen von ID: <ul><li>Fixed Offsets - ein vollständig aufgelöster Offset von UTC/Greenwich, der denselben Offset für alle lokalen Datum-Uhrzeit-li-Regionen <verwendet>- ein Bereich, in dem eine bestimmte Regelsatz zum Ermitteln des Offsets von UTC/Greenwich apply </ul> Most fixed offsets durch ZoneOffsetdargestellt wird. Durch aufrufende #normalized() Elemente ZoneId wird sichergestellt, dass eine feste Offset-ID als ein ZoneOffset.

Die tatsächlichen Regeln, die beschreiben, wann und wie sich der Offset ändert, werden durch ZoneRulesdefiniert. Diese Klasse ist einfach eine ID, die zum Abrufen der zugrunde liegenden Regeln verwendet wird. Dieser Ansatz wird ergriffen, da Regeln von Regierungen definiert und häufig geändert werden, während die ID stabil ist.

Die Unterscheidung hat andere Auswirkungen. Durch die Serialisierung wird nur ZoneId die ID gesendet, während die Serialisierung der Regeln den gesamten Datensatz sendet. Ebenso untersucht ein Vergleich von zwei IDs nur die ID, während ein Vergleich zweier Regeln den gesamten Datensatz untersucht.

<h2>Zeitzonen-IDs</h2> Die ID ist innerhalb des Systems eindeutig. Es gibt drei Arten von ID.

Der einfachste Typ der ID ist dies von ZoneOffset. Dies besteht aus 'Z' und IDs beginnend mit '+' oder '-'.

Der nächste Id-Typ sind Offsetstil-IDs mit einer Präfixform, z. B. "GMT+2" oder "UTC+01:00". Die anerkannten Präfixe sind "UTC", "GMT" und "UT". Der Offset ist das Suffix und wird während der Erstellung normalisiert. Diese IDs können auf eine ZoneOffset Verwendung normalized()normalisiert werden.

Der dritte ID-Typ sind regionsbasierte IDs. Eine regionsbasierte ID muss aus zwei oder mehr Zeichen bestehen und nicht mit "UTC", "GMT", "UT" "+" oder "-" beginnen. Regionsbasierte IDs werden durch die Konfiguration definiert. Die Konfiguration konzentriert sich auf die Bereitstellung der Suche von der ID bis zur zugrunde liegenden ZoneRules.

Zeitzonenregeln werden von Regierungen definiert und ändern sich häufig. Es gibt eine Reihe von Organisationen, die hier als Gruppen bezeichnet werden, die Zeitzonenänderungen überwachen und zusammenführen. Die Standardgruppe ist die IANA-Zeitzonendatenbank (TZDB). Andere Organisationen umfassen IATA (Fluggesellschaftenindustrie) und Microsoft.

Jede Gruppe definiert ein eigenes Format für die von ihr bereitgestellte Regions-ID. Die TZDB-Gruppe definiert IDs wie "Europe/London" oder "America/New_York". TZDB-IDs haben Vorrang vor anderen Gruppen.

Es wird dringend empfohlen, dass der Gruppenname in allen IDs enthalten ist, die von anderen Gruppen als TZDB bereitgestellt werden, um Konflikte zu vermeiden. IATA-Zeitzonen-Regions-IDs sind z. B. in der Regel identisch mit dem drei buchstabenigen Flughafencode.For example, IATA airline time-zone region IDs are typically the same as the three letter airport code. Der Flughafen Utrecht hat jedoch den Code "UTC", der offensichtlich ein Konflikt ist. Das empfohlene Format für Regions-IDs aus anderen Gruppen als TZDB lautet "group~region". Wenn also IATA-Daten definiert wurden, wäre der Flughafen Utrecht "IATA~UTC".

<h2>Serialisierung</h2> Diese Klasse kann serialisiert werden und speichert die Zeichenfolgenzonen-ID im externen Formular. Die ZoneOffset Unterklasse verwendet ein dediziertes Format, das nur den Offset von UTC/Greenwich speichert.

A ZoneId kann in einer Java Runtime deserialisiert werden, in der die ID unbekannt ist. Wenn beispielsweise eine serverseitige Java Runtime mit einer neuen Zonen-ID aktualisiert wurde, die clientseitige Java Runtime jedoch nicht aktualisiert wurde. In diesem Fall ist das ZoneId Objekt vorhanden und kann mithilfe getIdvon , equals, , hashCode, toStringund getDisplayName .normalized Allerdings schlägt jeder Aufruf getRules mit ZoneRulesException. Dieser Ansatz wurde entwickelt, um das ZonedDateTime Laden und Abfragen, aber nicht geändert, auf einer Java Runtime mit unvollständigen Zeitzoneninformationen zu ermöglichen.

Hinzugefügt in 1.8.

Java Dokumentation für java.time.ZoneId.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.