Temporal.ZonedDateTime

Beschreibung

Ein ZonedDateTime fungiert als Brücke zwischen einer exakten Zeit und einer "Wanduhrzeit": Es repräsentiert gleichzeitig einen Moment in der Geschichte (wie ein Temporal.Instant) und eine lokale, "Wanduhrzeit" (wie ein Temporal.PlainDateTime). Dies geschieht durch Speichern des Moments, der Zeitzone und des Kalendersystems. Die Zeitzone wird verwendet, um zwischen dem Moment und der lokalen Zeit zu konvertieren, und das Kalendersystem wird verwendet, um die lokale Zeit zu interpretieren.

ZonedDateTime ist die einzige Temporal-Klasse, die sich der Zeitzone bewusst ist. Die Hinzufügung einer Zeitzone führt dazu, dass ZonedDateTime-Objekte wichtige Verhaltensunterschiede zu Temporal.PlainDateTime-Objekten aufweisen. Nämlich, Sie können nicht mehr davon ausgehen, dass "die Zeit 1 Minute später" jeden Tag gleich ist oder dass ein Tag 24 Stunden hat. Im schlimmsten Fall kann ein ganzer Tag im lokalen Kalender fehlen. Unten bieten wir einen kurzen Überblick über Zeitzonen und Offsets und wie sie die Umwandlung zwischen UTC-Zeit und lokaler Zeit beeinflussen.

Zeitzonen und Offsets

Alle Zeiten in JavaScript haben einen goldenen Standard: die UTC-Zeit, die kontinuierlich und gleichmäßig zunimmt, während die physikalische Zeit fortschreitet. Im Gegensatz dazu sind Benutzer mehr an ihrer lokalen Zeit interessiert, die Zeit, die sie auf ihren Kalendern und Uhren ablesen. Der Prozess der Umwandlung zwischen UTC-Zeit und lokaler Zeit beinhaltet einen Zeitzonen-Offset, der wie folgt berechnet wird:

local time = UTC time + offset

Zum Beispiel, wenn die UTC-Zeit 1970-01-01T00:00:00 ist und der Offset "-05:00" beträgt, dann ist die lokale Zeit:

1970-01-01T00:00:00 + -05:00 = 1969-12-31T19:00:00

Durch Anhängen dieser lokalen Zeit mit dem Offset, also durch Ausdruck dieser Zeit als "1969-12-31T19:00:00-05:00", kann sie nun unmissverständlich als ein Moment in der Geschichte verstanden werden.

Um den Offset zu kennen, benötigen wir zwei Informationen, die Zeitzone und den Moment. Die Zeitzone ist eine Region auf der Erde, in der der gleiche Offset zu allen Zeiten verwendet wird. Zwei Uhren in derselben Zeitzone werden immer gleichzeitig die gleiche Zeit anzeigen, aber der Offset ist nicht unbedingt konstant: das heißt, diese Uhrenzeiten können sich abrupt ändern. Dies geschieht häufig während der Sommerzeitumstellung, wenn sich der Offset um eine Stunde ändert, was zweimal im Jahr geschieht. Offsets können sich auch dauerhaft durch politische Veränderungen ändern, z.B. wenn ein Land die Zeitzonen wechselt.

Die Zeitzonen sind in der IANA-Zeitzonendatenbank gespeichert. Jede IANA-Zeitzone hat:

• Einen primären Zeitzonenbezeichner, der die Zeitzone eindeutig identifiziert. Er bezieht sich normalerweise auf einen geografischen Bereich, der durch eine Stadt verankert ist (z.B. Europe/Paris oder Africa/Kampala), kann aber auch Einzel-Offset-Zeitzonen wie UTC (ein konstanter +00:00 Offset) oder Etc/GMT+5 bezeichnen (was aus historischen Gründen ein negativer Offset -05:00 ist). Aus historischen Gründen ist der primäre Name für die UTC-Zeitzone UTC, obwohl er in IANA Etc/UTC ist.
• Eine Zeitzonendefinition in Form einer Tabelle, die UTC-Datums-/Zeitbereiche (einschließlich zukünftiger Bereiche) auf bestimmte Offsets abbildet.
• Null oder mehr nicht primäre Zeitzonenbezeichner, die Aliase für den primären Zeitzonenbezeichner sind. Diese sind normalerweise historische Namen, die nicht mehr verwendet werden, aber aus Kompatibilitätsgründen beibehalten werden. Siehe unten für weitere Informationen.

Die Eingabe benannter Bezeichner erfolgt ohne Berücksichtigung der Groß- und Kleinschreibung. Intern werden sie in ihrer bevorzugten Schreibweise gespeichert, und nicht primäre Bezeichner werden nicht zu ihrem primären Bezeichner konvertiert.

Wenn eine Temporal-API einen Zeitzonenbezeichner akzeptiert, akzeptiert sie neben primären Zeitzonenbezeichnern und nicht primären Zeitzonenbezeichnern auch einen Offset-Zeitzonenbezeichner, der in derselben Form wie der Offset ist, außer dass Präzision unter einer Minute nicht erlaubt ist. Zum Beispiel sind +05:30, -08, +0600 alle gültige Offset-Bezeichner. Intern werden Offset-Bezeichner in der Form ±HH:mm gespeichert.

Zur Bequemlichkeit können Sie beim Bereitstellen eines Zeitzonenbezeichners an Temporal-APIs wie Temporal.ZonedDateTime.prototype.withTimeZone() und die timeZoneId-Option von Temporal.ZonedDateTime.from() diesen in einigen anderen Formen bereitstellen:

• Als eine andere ZonedDateTime-Instanz, deren timeZoneId verwendet wird.
• Als eine RFC 9557-String mit einer Zeitzonenanmerkung, deren Zeitzonenbezeichner verwendet wird.
• Als ein ISO 8601 / RFC 3339-String, der einen Offset enthält, dessen Offset als Offset-Bezeichner verwendet wird; oder, wenn Z verwendet wird, dann wird die "UTC" Zeitzone verwendet. Diese Nutzung wird generell nicht empfohlen, da, wie oben erläutert, Offset-Bezeichner nicht in der Lage sind, andere Temporal.ZonedDateTime-Instanzen sicher über einen Offset-Übergang hinweg abzuleiten, wie wenn die Sommerzeit beginnt oder endet. Erwägen Sie stattdessen, einfach Temporal.Instant zu verwenden oder die tatsächliche benannte Zeitzone des Benutzers abzurufen.

Die IANA-Zeitzonendatenbank ändert sich von Zeit zu Zeit, normalerweise um neue Zeitzonen als Reaktion auf politische Änderungen hinzuzufügen. Gelegentlich werden IANA-Zeitzonenbezeichner umbenannt, um die aktualisierte englische Übersetzung eines Städtenamens wiederzugeben oder um veraltete Namenskonventionen zu aktualisieren. Zum Beispiel hier sind einige bemerkenswerte Namensänderungen:

Historisch gesehen verursachten diese Umbenennungen Probleme für Programmierer, weil die Unicode CLDR-Datenbank (eine von Browsern verwendete Bibliothek zur Bereitstellung von Zeitzonenbezeichnern und -daten) aus Stabilitätsgründen iaas Namensänderungen nicht folgte. Infolgedessen berichteten einige Browser wie Chrome und Safari von den veralteten Bezeichnern von CLDR, während andere Browser wie Firefox die Standardeinstellungen von CLDR überschrieben und die aktuellen primären Bezeichner berichteten.

Mit der Einführung von Temporal ist dieses Verhalten jetzt standardisierter:

• CLDR-Daten enthalten jetzt das "_iana"-Attribut, das den aktuellsten Bezeichner angibt, wenn der ältere, stabile Bezeichner umbenannt wurde. Browser können dieses neue Attribut verwenden, um Anrufern aktualisierte Bezeichner bereitzustellen.
• Zeitzonenbezeichner, die vom Programmierer bereitgestellt werden, werden niemals durch einen Alias ersetzt. Zum Beispiel, wenn der Anrufer Asia/Calcutta oder Asia/Kolkata als Bezeichner für die Eingabe in Temporal.ZonedDateTime.from() bereitstellt, dann wird derselbe Bezeichner im resultierenden Instanz timeZoneId zurückgegeben. Beachten Sie, dass die Groß-/Kleinschreibung der Ausgaben normalisiert wird, um mit IANA übereinzustimmen, sodass ASIA/calCuTTa als Eingabe einen timeZoneId von Asia/Calcutta als Ausgabe generiert.
• Wenn ein Zeitzonenbezeichner nicht durch einen Anrufer bereitgestellt wird, sondern stattdessen vom System selbst bezogen wird (zum Beispiel bei der Verwendung von Temporal.Now.timeZoneId()), werden moderne Bezeichner in allen Browsern zurückgegeben. Bei Städtenamen-Umbenennungen gibt es eine zweijährige Verzögerung, bevor diese systembereitgestellten Bezeichner-APIs den neuen Namen offenlegen, wodurch anderen Komponenten (wie einem Node-Server) Zeit gegeben wird, ihre Kopien der IANA-Datenbank zu aktualisieren, um den neuen Namen zu erkennen.

Beachten Sie, dass die Zuordnung primärer Bezeichner den Ländercode beibehält: Zum Beispiel zeichnet die IANA-Datenbank Atlantic/Reykjavik als Alias für Africa/Abidjan auf, aber da sie verschiedenen Ländern (Island und Côte d'Ivoire, bzw.) entsprechen, werden sie als separate primäre Bezeichner behandelt.

Diese Standardisierung gilt auch außerhalb von Temporal. Zum Beispiel wird die timeZone-Option, die von Intl.DateTimeFormat.prototype.resolvedOptions() zurückgegeben wird, ebenfalls niemals durch einen Alias ersetzt, obwohl Browser diese Bezeichner vor der Standardisierung durch Temporal traditionell kanonisierten. Andererseits geben Intl.Locale.prototype.getTimeZones() und Intl.supportedValuesOf() (timeZone-Option) den aktuellsten Bezeichner zurück, während einige Browser die alte, nicht primäre Bezeichnung zurückgaben.

RFC 9557 Format

ZonedDateTime-Objekte können im RFC 9557-Format serialisiert und geparst werden, eine Erweiterung des ISO 8601 / RFC 3339-Formats. Der String hat folgendes Format (Leerzeichen sind nur der Lesbarkeit wegen und sollten im tatsächlichen String nicht vorhanden sein):

YYYY-MM-DD T HH:mm:ss.sssssssss Z/±HH:mm [time_zone_id] [u-ca=calendar_id]

YYYY

Entweder eine vierstellige Zahl oder eine sechsstellige Zahl mit einem + oder - Zeichen.

MM

Eine zweistellige Zahl von 01 bis 12.

DD

Eine zweistellige Zahl von 01 bis 31. Die YYYY, MM und DD Komponenten können durch - oder nichts getrennt werden.

T Optional

Der Datums-Zeit-Trenner, der T, t oder ein Leerzeichen sein kann. Nur vorhanden, wenn HH vorhanden ist.

HH Optional

Eine zweistellige Zahl von 00 bis 23. Standard ist 00.

mm Optional

Eine zweistellige Zahl von 00 bis 59. Standard ist 00.

ss.sssssssss Optional

Eine zweistellige Zahl von 00 bis 59. Kann optional von einem . oder , und einer bis neun Ziffern gefolgt werden. Standard ist 00. Die HH, mm und ss Komponenten können durch : oder nichts getrennt werden. Sie können entweder nur ss oder sowohl ss als auch mm weglassen, sodass die Zeit in einer von drei Formen sein kann: HH, HH:mm oder HH:mm:ss.sssssssss.

Z/±HH:mm Optional

Entweder der UTC-Bezeichner Z oder z oder ein Offset von UTC in der Form + oder -, gefolgt vom selben Format wie die Zeitkomponente. Beachten Sie, dass Subminuten-Präzision (:ss.sssssssss) von anderen Systemen möglicherweise nicht unterstützt wird und akzeptiert ist, aber nie ausgegeben wird. Wenn es weggelassen wird, wird das Offset vom Zeitzonenbekannter abgeleitet. Wenn es vorhanden ist, muss die Zeit auch bereitgestellt werden. Z entspricht nicht +00:00: Ersteres bedeutet, dass die Zeit unabhängig vom Zeitzonenbekannter in UTC-Form angegeben wird, während Letzteres bedeutet, dass die Zeit in lokaler Zeit angegeben wird, die zufällig UTC+0 ist, und wird gegen den Zeitzonenbekannter durch die offset-Option validiert.

[time_zone_id]

Ersetzen Sie time_zone_id durch den Zeitzonenbezeichner (benannt oder Offset) wie oben beschrieben. Kann ein kritisches Flag haben, indem der Bezeichner mit ! vorangestellt wird: z.B. [!America/New_York]. Dieses Flag signalisiert anderen Systemen im Allgemeinen, dass es nicht ignoriert werden kann, wenn sie es nicht unterstützen. Beachten Sie, dass es für Temporal.ZonedDateTime.from() erforderlich ist: Das Weglassen führt zu einem RangeError. Wenn Sie ISO 8601 / RFC 3339-Strings ohne Zeitzonenkennungsanmerkungen parsen möchten, verwenden Sie Temporal.Instant.from() stattdessen.

[u-ca=calendar_id] Optional

Ersetzen Sie calendar_id durch den zu verwendenden Kalender. Siehe Intl.supportedValuesOf() für eine Liste der allgemein unterstützten Kalendertypen. Standard ist [u-ca=iso8601]. Kann ein kritisches Flag haben, indem der Schlüssel mit ! vorangestellt wird: z.B. [!u-ca=iso8601]. Dieses Flag signalisiert anderen Systemen im Allgemeinen, dass es nicht ignoriert werden kann, wenn sie es nicht unterstützen. Der Temporal-Parser wird einen Fehler auslösen, wenn die Anmerkungen zwei oder mehr Kalenderanmerkungen enthalten und eine davon kritisch ist. Beachten Sie, dass die YYYY-MM-DD immer als ISO 8601-Kalenderdatum interpretiert wird und dann in den angegebenen Kalender konvertiert wird.

Als Eingabe werden andere Anmerkungen im Format [key=value] ignoriert und dürfen kein kritisches Flag haben.

Beim Serialisieren können Sie die Bruchteile der Sekunden, die Offset-/Zeitzonen-/Kalender-ID, und ob ein kritisches Flag für die Anmerkungen hinzugefügt werden soll, konfigurieren.

Mehrdeutigkeit und Lücken von lokaler Zeit zu UTC-Zeit

Unter der Annahme einer Zeitzone ist die Umwandlung von UTC in lokale Zeit einfach: Sie ermitteln zuerst den Offset mit dem Zeitzonennamen und dem Moment und addieren dann den Offset zu dem Moment. Das Gegenteil ist nicht der Fall: Eine Umwandlung von lokaler Zeit zu UTC-Zeit, ohne einen expliziten Offset, ist mehrdeutig, da eine lokale Zeit null, einem oder vielen UTC-Zeiten entspricht. Betrachten Sie die häufigste Ursache: Sommerzeitumstellungen. Nehmen wir New York als Beispiel. Sein Standardoffset ist UTC-5, aber während der Normalzeit werden alle Uhren eine Stunde vorgedreht, sodass der Offset UTC-4 wird. In den USA finden die Übergänge um 2:00 Uhr Ortszeit statt, also betrachten Sie diese zwei Übergangstage:

Wie Sie sehen, ist im März eine Stunde von der lokalen Zeit verschwunden, und im November gibt es zwei Stunden, die dieselbe Wanduhrzeit haben. Angenommen, wir haben ein PlainDateTime gespeichert, das "2024-03-10T02:05:00" sagt, und wir sollen es in der America/New_York-Zeitzone interpretieren, wird es keine Zeit geben, die ihm entspricht, während ein PlainDateTime, das "2024-11-03T01:05:00" sagt, zwei verschiedenen Momenten entsprechen kann.

Beim Erstellen eines ZonedDateTime aus einer lokalen Zeit (mithilfe von Temporal.ZonedDateTime.from(), Temporal.ZonedDateTime.prototype.with(), Temporal.PlainDateTime.prototype.toZonedDateTime()), ist das Verhalten für Mehrdeutigkeit und Lücken über die disambiguation-Option konfigurierbar:

earlier

Wenn es zwei mögliche Momente gibt, wählen Sie den früheren. Wenn es eine Lücke gibt, gehen Sie zurück um die Dauer der Lücke.

later

Wenn es zwei mögliche Momente gibt, wählen Sie den späteren. Wenn es eine Lücke gibt, gehen Sie vorwärts um die Dauer der Lücke.

compatible (Standard)

Gleiches Verhalten wie Date: verwenden Sie later für Lücken und earlier für Mehrdeutigkeiten.

reject

Werfen Sie einen RangeError, wann immer es eine Mehrdeutigkeit oder Lücke gibt.

Es gibt mehrere Fälle, in denen es keine Mehrdeutigkeit gibt, wenn ein ZonedDateTime konstruiert wird:

• Wenn die Zeit in UTC über den Z-Offset angegeben ist.
• Wenn der Offset explizit bereitgestellt und verwendet wird (siehe unten).

Offset-Mehrdeutigkeit

Wir haben bereits gezeigt, wie Mehrdeutigkeit durch das Interpretieren einer lokalen Zeit in einer Zeitzone entstehen kann, ohne einen expliziten Offset bereitzustellen. Wenn Sie jedoch einen expliziten Offset bereitstellen, entsteht ein weiterer Konflikt: zwischen dem angegebenen Offset und dem aus der Zeitzone und der lokalen Zeit berechneten Offset. Dies ist ein unvermeidbares reales Problem: Wenn Sie eine Zeit in der Zukunft mit einem vorhergesagten Offset speichern, kann sich die Zeitzonendefinition vor diesem Zeitpunkt aus politischen Gründen ändern. Beispielsweise nehmen wir an, dass wir im Jahr 2018 eine Erinnerung zum Zeitpunkt 2019-12-23T12:00:00-02:00[America/Sao_Paulo] (was Normalzeit ist; Brasilien liegt auf der Südhalbkugel und tritt im Oktober in die Normalzeit ein und verlässt sie im Februar) einrichten. Aber bevor diese Zeit eintritt, beschließt Brasilien Anfang 2019, die Normalzeit nicht mehr zu beachten, sodass der echte Offset -03:00 wird. Sollte die Erinnerung jetzt noch um Mittag (mit der Beibehaltung der lokalen Zeit) ausgeführt werden, oder sollte sie um 11:00 Uhr (mit der Beibehaltung der genauen Zeit) ausgeführt werden?

Damit eine Offset-Mehrdeutigkeit besteht, muss ein Zeitstempelstring unter Verwendung anderer IANA-Zeitzonendatenbankregeln geparst werden als die Regeln, die verwendet wurden, als der Zeitstempel ursprünglich generiert wurde. Dies wird niemals passieren, wenn Zeitstempel während derselben Ausführung eines JavaScript-Programms generiert werden, da gemäß der ECMAScript-Spezifikation die IANA-Zeitzonendatenbankregeln während der Lebensdauer eines JavaScript-Programms konsistent sein müssen.

Jedoch kann eine Offset-Mehrdeutigkeit bestehen, wenn ein JavaScript-Programm Zeitstempel parst, die früher gespeichert wurden, wie im oben erwähnten America/Sao_Paulo-Beispiel, und die IANA-Zeitzonendatenbank seit der ursprünglichen Generierung des Zeitstempels aktualisiert wurde. Es kann auch vorkommen, wenn Zeitstempel zwischen Computern (oder selten zwischen verschiedenen Software auf demselben Computer!) kommuniziert werden, die unterschiedliche Versionen der IANA-Zeitzonendatenbank verwenden. Die IANA-Zeitzonendatenbank hat auch Build-Optionen (z.B. die Verwendung oder Nichtverwendung veralteter Regeln in backzone), die zu Offset-Mehrdeutigkeit führen können, wenn Zeitstempel zwischen Computern mit unterschiedlicher Software ausgetauscht werden, selbst wenn die IANA-Zeitzonendatenbankversion dieselbe ist.

Offset-Mehrdeutigkeit wird selten angetroffen und betrifft fast immer nur Zeitstempel vor 1970 oder Zeitstempel, die Monate oder Jahre in der Zukunft liegen. Aber wenn dieses Problem auftritt, wird standardmäßig ein RangeError ausgelöst. Wenn ein ZonedDateTime mit Temporal.ZonedDateTime.from() konstruiert oder es mit der with()-Methode aktualisiert wird, können Sie diese Ausnahme vermeiden, indem Sie die offset-Option verwenden, um zu entscheiden, ob der Offset oder der Zeitzonenbezeichner "gewinnt":

use

Verwenden Sie den Offset, um die genaue Zeit zu berechnen. Diese Option "verwendet" den Offset, um den Moment zu bestimmen, der durch den Zeitstempelstring beabsichtigt ist, selbst wenn sich der Offset zu diesem Zeitpunkt geändert hat. Der Zeitzonenbezeichner wird dennoch verwendet, um den (möglicherweise aktualisierten) Offset zu bestimmen und diesen Offset zu verwenden, um die genaue Zeit in lokale Zeit zu konvertieren. Im oben genannten Beispiel 2019-12-23T12:00:00-02:00[America/Sao_Paulo] würde diese Option dazu führen, dass die Erinnerung um 11:00 Uhr Ortszeit ausgeführt wird.

ignore

Ignorieren Sie den im String angegebenen Offset und verwenden Sie den Zeitzonenbezeichner, um den Offset neu zu berechnen. Diese Option behält die gleiche lokale Zeit wie ursprünglich berechnet, als wir die Zeit speicherten, aber sie kann zu einem anderen Moment führen. Beachten Sie, dass durch Ignorieren des Offsets die gleiche lokale Zeitinterpretationsmehrdeutigkeit entstehen kann, die mit der disambiguation-Option gelöst wird. Im oben genannten Beispiel 2019-12-23T12:00:00-02:00[America/Sao_Paulo] würde diese Option dazu führen, dass die Erinnerung um 12:00 Uhr Ortszeit ausgeführt wird.

reject

Werfen Sie einen RangeError, wenn es einen Konflikt zwischen dem Offset und dem Zeitzonenbezeichner gibt. Dies ist der Standard für Temporal.ZonedDateTime.from().

prefer

Verwenden Sie den Offset, wenn er gültig ist, berechnen Sie andernfalls den Offset aus dem Zeitzonenbezeichner. Dies ist der Standard für Temporal.ZonedDateTime.prototype.with() (siehe diese Methode für weitere Details). Dies unterscheidet sich von ignore, da im Falle einer lokalen Zeitmehrdeutigkeit der Offset verwendet wird, um sie zu lösen, anstatt der disambiguation-Option.

Wenn Sie im Voraus wissen, wie Sie die Offset-Mehrdeutigkeit handhaben möchten, sollten Sie die offset-Option verwenden, um die standardmäßig geworfenen Ausnahmen zu vermeiden. Zum Beispiel möchte eine Kalenderanwendung wahrscheinlich, dass der Zeitzonenbezeichner "gewinnt", damit wiederkehrende Meetings in der aktuellsten lokalen Zeit für diese Zeitzone angezeigt werden, daher ist offset: "ignore" angemessen. Andererseits sollte eine Aufgabenplaner-Anwendung, die eine Aufgabe genau 3 Stunden ab jetzt ausführt, wahrscheinlich offset: "use" wählen, da Änderungen der Zeitzonenregeln nicht die Bedeutung von "3 Stunden ab jetzt" ändern sollten.

In einigen Fällen wissen Sie möglicherweise nicht, welche offset-Option die richtige ist, ohne die Benutzer um Input zu bitten. In diesen Fällen sollten Sie möglicherweise den RangeError abfangen und dann Ihren Benutzer fragen, welche lokale Zeit die richtige ist, und dann das Parsen mit einer anderen offset-Option basierend auf der Auswahl des Benutzers erneut versuchen.

Beachten Sie, dass der Z-Offset nicht gleich +00:00 ist. Der Z-Offset bedeutet "die Zeit in UTC ist bekannt, aber der Offset zur Ortszeit ist unbekannt", gemäß RFC 9557. Wenn der Zeitstring den Z-Offset verwendet, wird die offset-Option ignoriert, und der Offset wird vom Zeitzonen-ID abgeleitet. Andererseits wird der +00:00-Offset als ein lokaler Zeitoffset interpretiert, der zufällig mit UTC übereinstimmt und gegenüber dem Zeitzonen-ID bestätigt wird.

Konstruktor

Temporal.ZonedDateTime()

Erstellt ein neues Temporal.ZonedDateTime-Objekt durch direktes Bereitstellen der zugrunde liegenden Daten.

Statische Methoden

Temporal.ZonedDateTime.compare()

Gibt eine Zahl (-1, 0 oder 1) zurück, die angibt, ob der erste Datum-Zeit-Punkt vor, gleich oder nach dem zweiten Datum-Zeit-Punkt liegt. Entspricht dem Vergleich der epochNanoseconds der beiden Datum-Zeit-Punkte.

Temporal.ZonedDateTime.from()

Erstellt ein neues Temporal.ZonedDateTime-Objekt aus einem anderen Temporal.ZonedDateTime-Objekt, einem Objekt mit Datum, Zeit und Zeitzoneneigenschaften oder einem RFC 9557 String.

Instanz-Eigenschaften

Diese Eigenschaften sind auf Temporal.ZonedDateTime.prototype definiert und werden von allen Temporal.ZonedDateTime-Instanzen geteilt.

Temporal.ZonedDateTime.prototype.calendarId

Gibt einen String zurück, der den Kalender verwendet, um das interne ISO 8601-Datum zu interpretieren.

Temporal.ZonedDateTime.prototype.constructor

Die Konstruktionsfunktion, die das Instanzobjekt erstellt hat. Für Temporal.ZonedDateTime-Instanzen ist der anfängliche Wert der Temporal.ZonedDateTime()-Konstruktor.

Temporal.ZonedDateTime.prototype.day

Gibt eine positive Ganzzahl zurück, die den 1-basierten Tagesindex im Monat dieses Datums repräsentiert, was die gleiche Tagesnummer ist, die Sie auf einem Kalender sehen würden. Kalender-abhängig. Beginnt allgemein bei 1 und ist kontinuierlich, aber nicht immer.

Temporal.ZonedDateTime.prototype.dayOfWeek

Gibt eine positive Ganzzahl zurück, die den 1-basierten Tagesindex in der Woche dieses Datums repräsentiert. Tage in einer Woche werden der Reihe nach von 1 bis daysInWeek nummeriert, wobei jede Zahl ihrem Namen zugeordnet ist. Kalender-abhängig. 1 steht in der Regel für Montag im Kalender, selbst wenn Lokale, die den Kalender verwenden, einen anderen Tag als den ersten Tag der Woche betrachten können (siehe Intl.Locale.prototype.getWeekInfo()).

Temporal.ZonedDateTime.prototype.dayOfYear

Gibt eine positive Ganzzahl zurück, die den 1-basierten Tagesindex im Jahr dieses Datums repräsentiert. Der erste Tag dieses Jahres ist 1, und der letzte Tag ist der daysInYear. Kalender-abhängig.

Temporal.ZonedDateTime.prototype.daysInMonth

Gibt eine positive Ganzzahl zurück, die die Anzahl der Tage im Monat dieses Datums repräsentiert. Kalender-abhängig.

Temporal.ZonedDateTime.prototype.daysInWeek

Gibt eine positive Ganzzahl zurück, die die Anzahl der Tage in der Woche dieses Datums repräsentiert. Kalender-abhängig. Für den ISO 8601-Kalender sind dies immer 7, aber in anderen Kalendersystemen kann es von Woche zu Woche variieren.

Temporal.ZonedDateTime.prototype.daysInYear

Gibt eine positive Ganzzahl zurück, die die Anzahl der Tage im Jahr dieses Datums repräsentiert. Kalender-abhängig. Für den ISO 8601-Kalender sind dies 365 oder 366 in einem Schaltjahr.

Temporal.ZonedDateTime.prototype.epochMilliseconds

Gibt eine Ganzzahl zurück, die die Anzahl der Millisekunden darstellt, die seit der Unix-Epoche (Mitternacht zu Beginn des 1. Januar 1970, UTC) bis zu diesem Moment verstrichen sind. Entspricht der Division von epochNanoseconds durch 1e6 und dem Abrunden des Ergebnisses.

Temporal.ZonedDateTime.prototype.epochNanoseconds

Gibt ein BigInt zurück, das die Anzahl der Nanosekunden darstellt, die seit der Unix-Epoche (Mitternacht zu Beginn des 1. Januar 1970, UTC) bis zu diesem Moment verstrichen sind.

Temporal.ZonedDateTime.prototype.era

Gibt einen kalenderspezifischen Kleinbuchstabenstring zurück, der die Ära dieses Datums darstellt, oder undefined, wenn der Kalender keine Ären verwendet (z.B. ISO 8601). era und eraYear zusammen identifizieren ein Jahr in einem Kalender eindeutig, auf dieselbe Weise wie year. Kalender-abhängig. Für Gregorianisch ist es entweder "ce" oder "bce".

Temporal.ZonedDateTime.prototype.eraYear

Gibt eine nicht-negative Ganzzahl zurück, die das Jahr dieses Datums innerhalb der Ära darstellt, oder undefined, wenn der Kalender keine Ären verwendet (z.B. ISO 8601). Der Jahresindex beginnt gewöhnlich bei 1 (häufiger) oder 0, und Jahre in einer Ära können mit der Zeit abnehmen (z.B. Gregorianisch v. Chr.). era und eraYear zusammen identifizieren ein Jahr in einem Kalender eindeutig, auf dieselbe Weise wie year. Kalender-abhängig.

Temporal.ZonedDateTime.prototype.hour

Gibt eine Ganzzahl von 0 bis 23 zurück, die die Stundenkomponente dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.hoursInDay

Gibt eine positive Ganzzahl zurück, die die Anzahl der Stunden im Tag dieses Datums in der Zeitzone darstellt. Es kann mehr oder weniger als 24 sein, im Falle von Offset-Änderungen wie der Sommerzeit.

Temporal.ZonedDateTime.prototype.inLeapYear

Gibt einen booleschen Wert zurück, der anzeigt, ob dieses Datum in einem Schaltjahr liegt. Ein Schaltjahr ist ein Jahr, das mehr Tage (aufgrund eines Schalttages oder Schaltmonats) als ein gewöhnliches Jahr hat. Kalender-abhängig.

Temporal.ZonedDateTime.prototype.microsecond

Gibt eine Ganzzahl von 0 bis 999 zurück, die die Mikrosekundenkomponente (10^-6 Sekunden) dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.millisecond

Gibt eine Ganzzahl von 0 bis 999 zurück, die die Millisekundenkomponente (10^-3 Sekunden) dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.minute

Gibt eine Ganzzahl von 0 bis 59 zurück, die die Minutenkomponente dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.month

Gibt eine positive Ganzzahl zurück, die den 1-basierten Monatsindex im Jahr dieses Datums darstellt. Der erste Monat dieses Jahres ist 1, und der letzte Monat ist der monthsInYear. Kalender-abhängig. Beachten Sie, dass im Gegensatz zu Date.prototype.getMonth() der Index 1-basiert ist. Wenn der Kalender Schaltmonate hat, dann kann der Monat mit dem gleichen monthCode unterschiedliche month-Indizes für verschiedene Jahre haben.

Temporal.ZonedDateTime.prototype.monthCode

Gibt einen kalenderspezifischen String zurück, der den Monat dieses Datums darstellt. Kalender-abhängig. Normalerweise ist es M plus eine zweistellige Monatsnummer. Für Schaltmonate ist es der Code des vorherigen Monats gefolgt von L. Wenn der Schaltmonat der erste Monat des Jahres ist, lautet der Code M00L.

Temporal.ZonedDateTime.prototype.monthsInYear

Gibt eine positive Ganzzahl zurück, die die Anzahl der Monate im Jahr dieses Datums darstellt. Kalender-abhängig. Für den ISO 8601-Kalender sind es immer 12, aber in anderen Kalendersystemen kann es variieren.

Temporal.ZonedDateTime.prototype.nanosecond

Gibt eine Ganzzahl von 0 bis 999 zurück, die die Nanosekundenkomponente (10^-9 Sekunden) dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.offset

Gibt einen String zurück, der den Offset darstellt, der verwendet wird, um den inneren Moment zu interpretieren, in der Form ±HH:mm (oder ±HH:mm:ss.sssssssss mit so viel Subminutenpräzision wie nötig).

Temporal.ZonedDateTime.prototype.offsetNanoseconds

Gibt eine Ganzzahl zurück, die den Offset darstellt, der verwendet wird, um den inneren Moment zu interpretieren, als Anzahl der Nanosekunden (positiv oder negativ).

Temporal.ZonedDateTime.prototype.second

Gibt eine Ganzzahl von 0 bis 59 zurück, die die Sekundenkomponente dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.timeZoneId

Gibt einen String zurück, der den Zeitzonenbezeichner darstellt, der verwendet wird, um den inneren Moment zu interpretieren. Es verwendet den gleichen String, der beim Erstellen des Temporal.ZonedDateTime-Objekts verwendet wurde, der entweder ein IANA-Zeitzonenname oder ein fester Offset ist.

Temporal.ZonedDateTime.prototype.weekOfYear

Gibt eine positive Ganzzahl zurück, die den 1-basierten Wochenindex im yearOfWeek dieses Datums darstellt, oder undefined, wenn der Kalender kein gut definiertes Wochensystem hat. Die erste Woche des Jahres ist 1. Kalender-abhängig. Beachten Sie, dass für ISO 8601 die ersten und letzten Tage des Jahres der letzten Woche des Vorjahres oder der ersten Woche des nächsten Jahres zugeordnet sein können.

Temporal.ZonedDateTime.prototype.year

Gibt eine Ganzzahl zurück, die die Anzahl der Jahre dieses Datums relativ zum Beginn des spezifischen Epochejahres des Kalenders darstellt. Kalender-abhängig. Normalerweise ist Jahr 1 entweder das erste Jahr der neuesten Ära oder das ISO 8601 Jahr 0001. Wenn die Epoche in der Mitte des Jahres beginnt, hat dieses Jahr den gleichen Wert vor und nach dem Startdatum der Ära.

Temporal.ZonedDateTime.prototype.yearOfWeek

Gibt eine Ganzzahl zurück, die das Jahr darstellt, das mit dem weekOfYear dieses Datums gepaart werden soll, oder undefined, wenn der Kalender kein gut definiertes Wochensystem hat. Kalender-abhängig. Normalerweise ist dies das Jahr des Datums, aber für ISO 8601 können die ersten und letzten Tage des Jahres der letzten Woche des Vorjahres oder der ersten Woche des nächsten Jahres zugeordnet sein, was dazu führt, dass sich das yearOfWeek um 1 unterscheidet.

Temporal.ZonedDateTime.prototype[Symbol.toStringTag]

Der anfängliche Wert der [Symbol.toStringTag]-Eigenschaft ist der String "Temporal.ZonedDateTime". Diese Eigenschaft wird in Object.prototype.toString() verwendet.

Instanzmethoden

Temporal.ZonedDateTime.prototype.add()

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diesen Datum-Zeit-Punkt um eine bestimmte Dauer (in einem Formular, das von Temporal.Duration.from() konvertierbar ist) nach vorne verschoben darstellt.

Temporal.ZonedDateTime.prototype.equals()

Gibt true zurück, wenn dieser Datum-Zeit-Punkt in Bezug auf einen anderen Datum-Zeit-Punkt (in einem Formular, das von Temporal.ZonedDateTime.from() konvertierbar ist) wertgleich ist, und false andernfalls. Sie werden sowohl anhand ihrer Momentwerte, Zeitzonen und ihrer Kalender verglichen, sodass zwei Datum-Zeit-Punkte aus verschiedenen Kalendern oder Zeitzonen von Temporal.ZonedDateTime.compare() als gleich angesehen werden können, jedoch nicht von equals().

Temporal.ZonedDateTime.prototype.getTimeZoneTransition()

Gibt ein Temporal.ZonedDateTime-Objekt zurück, das den ersten Moment nach oder vor diesem Moment darstellt, an dem sich der UTC-Offset der Zeitzone ändert, oder null, wenn es keinen solchen Übergang gibt. Dies ist nützlich, um die Offset-Regeln einer Zeitzone herauszufinden, wie ihr Sommerzeitmuster.

Temporal.ZonedDateTime.prototype.round()

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diesen Datum-Zeit-Punkt auf die angegebene Einheit gerundet darstellt.

Temporal.ZonedDateTime.prototype.since()

Gibt ein neues Temporal.Duration-Objekt zurück, das die Dauer von einem anderen Datum-Zeit-Punkt (in einem Formular, das von Temporal.ZonedDateTime.from() konvertierbar ist) bis zu diesem Datum-Zeit-Punkt darstellt. Die Dauer ist positiv, wenn der andere Datum-Zeit-Punkt vor diesem Datum-Zeit-Punkt liegt, und negativ, wenn danach.

Temporal.ZonedDateTime.prototype.startOfDay()

Gibt ein Temporal.ZonedDateTime-Objekt zurück, das den ersten Moment dieses Datums in der Zeitzone darstellt. Es hat normalerweise eine Zeit von 00:00:00, kann jedoch unterschiedlich sein, wenn das Mitternachtszeit wegen Offset-Änderungen nicht existiert, in welchem Fall die erste vorhandene Zeit zurückgegeben wird.

Temporal.ZonedDateTime.prototype.subtract()

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diesen Datum-Zeit-Punkt um eine bestimmte Dauer (in einem Formular, das von Temporal.Duration.from() konvertierbar ist) nach hinten verschoben darstellt.

Temporal.ZonedDateTime.prototype.toInstant()

Gibt ein neues Temporal.Instant-Objekt zurück, das den Moment dieses Datum-Zeit-Punktes darstellt.

Temporal.ZonedDateTime.prototype.toJSON()

Gibt einen String zurück, der diesen Datum-Zeit-Punkt im selben RFC 9557 Format wie beim Aufrufen von toString() darstellt. Soll implizit von JSON.stringify() aufgerufen werden.

Temporal.ZonedDateTime.prototype.toLocaleString()

Gibt einen String zurück, der eine sprachabhängige Darstellung dieses Datum-Zeit-Punktes enthält.

Temporal.ZonedDateTime.prototype.toPlainDate()

Gibt ein neues Temporal.PlainDate-Objekt zurück, das den Datumsanteil dieses Datum-Zeit-Punktes darstellt.

Temporal.ZonedDateTime.prototype.toPlainDateTime()

Gibt ein neues Temporal.PlainDateTime-Objekt zurück, das das Datum und die Zeitanteile dieses Datum-Zeit-Punktes darstellt. Nur die Zeitzoneninformationen werden entfernt.

Temporal.ZonedDateTime.prototype.toPlainTime()

Gibt ein neues Temporal.PlainTime-Objekt zurück, das den Zeitanteil dieses Datum-Zeit-Punktes darstellt.

Temporal.ZonedDateTime.prototype.toString()

Gibt einen String zurück, der diesen Datum-Zeit-Punkt im RFC 9557 Format darstellt.

Temporal.ZonedDateTime.prototype.until()

Gibt ein neues Temporal.Duration-Objekt zurück, das die Dauer von diesem Datum-Zeit-Punkt bis zu einem anderen Datum-Zeit-Punkt (in einem Formular, das von Temporal.ZonedDateTime.from() konvertierbar ist) darstellt. Die Dauer ist positiv, wenn der andere Datum-Zeit-Punkt nach diesem Datum-Zeit-Punkt liegt, und negativ, wenn davor.

Temporal.ZonedDateTime.prototype.valueOf()

Wirft einen TypeError, der verhindert, dass Temporal.ZonedDateTime-Instanzen implizit in Primitive umgewandelt werden, wenn sie in arithmetischen oder Vergleichsoperationen verwendet werden.

Temporal.ZonedDateTime.prototype.with()

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diesen Datum-Zeit-Punkt mit einigen Feldern darstellt, die durch neue Werte ersetzt wurden.

Temporal.ZonedDateTime.prototype.withCalendar()

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diesen Datum-Zeit-Punkt im neuen Kalendersystem interpretiert darstellt.

Temporal.ZonedDateTime.prototype.withPlainTime()

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diesen Datum-Zeit-Punkt darstellt, wobei der Zeitanteil vollständig durch die neue Zeit ersetzt wurde (in einem Formular, das von Temporal.PlainTime.from() konvertierbar ist).

Temporal.ZonedDateTime.prototype.withTimeZone()

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das denselben Moment wie dieser Datum-Zeit-Punkt darstellt, aber in der neuen Zeitzone.

Spezifikationen

Browser-Kompatibilität

Siehe auch

• Temporal
• Temporal.Duration
• Temporal.Instant
• Temporal.PlainDateTime
• Temporal.PlainDate
• Temporal.PlainTime