Temporal.ZonedDateTime

Ein ZonedDateTime fungiert als Brücke zwischen einer genauen Zeit und einer Wand-Uhrzeit: es repräsentiert gleichzeitig einen Moment in der Geschichte (wie ein Temporal.Instant) und eine lokale Wand-Uhrzeit (wie ein Temporal.PlainDateTime). Dies geschieht durch das 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 zeitzonenbewusst ist. Die Hinzufügung einer Zeitzone bewirkt, dass ZonedDateTime-Objekte wichtige Verhaltensunterschiede gegenüber Temporal.PlainDateTime-Objekten haben. Das bedeutet, dass Sie nicht mehr davon ausgehen können, dass "die Zeit 1 Minute danach" 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 Umrechnung zwischen UTC-Zeit und lokaler Zeit beeinflussen.

Alle Zeiten in JavaScript haben einen goldenen Standard: die UTC-Zeit, die sich kontinuierlich und gleichmäßig mit dem Fortschritt der physischen Zeit erhöht. Im Gegensatz dazu sind Benutzer mehr an ihrer lokalen Zeit interessiert, die sie auf ihren Kalendern und Uhren ablesen. Der Prozess der Umrechnung zwischen UTC-Zeit und lokaler Zeit beinhaltet ein Zeitzonen-Offset, das wie folgt berechnet wird:

local time = UTC time + offset

Zum Beispiel, wenn die UTC-Zeit 1970-01-01T00:00:00 ist, und das Offset "-05:00" lautet, dann ist die lokale Zeit:

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

Indem diese lokale Zeit mit dem Offset versehen wird, wird diese Zeit als "1969-12-31T19:00:00-05:00" ausgedrückt und kann nun eindeutig als ein Moment in der Geschichte verstanden werden.

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

Die Zeitzonen werden in der IANA Time Zone Database gespeichert. Jede IANA-Zeitzone hat:

• Einen primären Zeitzonen-Identifier, der die Zeitzone eindeutig identifiziert. Er bezieht sich in der Regel auf ein geografisches Gebiet, das durch eine Stadt verankert ist (z.B. Europe/Paris oder Africa/Kampala), kann aber auch Einzel-Offset-Zeitzonen wie UTC (ein konstantes +00:00-Offset) oder Etc/GMT+5 (aus historischen Gründen ein negatives Offset -05:00) benennen. 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-Datum-/Uhrzeitbereiche (einschließlich zukünftiger Bereiche) spezifischen Offsets zuordnet.
• Null oder mehr nicht-primäre Zeitzonen-Identifier, die Aliase des primären Zeitzonen-Identifiers sind. Diese sind in der Regel historische Namen, die nicht mehr verwendet werden, aber aus Kompatibilitätsgründen beibehalten werden. Weitere Informationen finden Sie unten.

Als Eingabe werden benannte Identifier ohne Beachtung der Groß- und Kleinschreibung abgeglichen. Intern werden sie in ihrer bevorzugten Schreibweise gespeichert, und nicht-primäre Identifier werden nicht in ihren primären Identifier umgewandelt.

Wenn eine Temporal-API einen Zeitzonen-Identifier akzeptiert, akzeptiert sie zusätzlich zu primären Zeitzonen-Identifiern und nicht-primären Zeitzonen-Identifiern auch einen Offset-Zeitzonen-Identifier, der in derselben Form wie das Offset ist, jedoch ist Präzision auf Minutenbasis nicht zulässig. Beispielsweise sind +05:30, -08, +0600 alle gültige Offset-Identifier. Intern werden Offset-Identifier in der Form ±HH:mm gespeichert.

Der Einfachheit halber, wenn Sie einen Zeitzonen-Identifier für Temporal-APIs wie Temporal.ZonedDateTime.prototype.withTimeZone() und die timeZoneId-Option von Temporal.ZonedDateTime.from() angeben, können Sie ihn in einigen anderen Formen angeben:

• Als eine andere ZonedDateTime-Instanz, deren timeZoneId verwendet wird.
• Als RFC 9557-String mit einer Zeitzonenanmerkung, deren Zeitzonen-Identifier verwendet wird.
• Als ISO 8601 / RFC 3339-String mit einem Offset, dessen Offset als Offset-Identifikator verwendet wird; oder, falls Z verwendet wird, wird die Zeitzone "UTC" verwendet. Diese Nutzung wird im Allgemeinen nicht empfohlen, da, wie oben diskutiert, Offset-Identifikatoren 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 zu ermitteln.

Die IANA-Zeitzonendatenbank ändert sich von Zeit zu Zeit, normalerweise um neue Zeitzonen als Reaktion auf politische Änderungen hinzuzufügen. In seltenen Fällen werden jedoch IANA-Zeitzonen-Identifier umbenannt, um aktualisierte englische Übersetzungen eines Stadtnamens zu übernehmen 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 Zeitzonen-Identifikatoren und -Daten) IANA-Umbenennungen aus Stabilitätsgründen nicht befolgte. Infolgedessen berichteten einige Browser wie Chrome und Safari über die veralteten CLDR-Identifikatoren, während andere Browser wie Firefox die Standardeinstellungen von CLDR überschrieben und die aktuellen Haupt-Identifikatoren gemeldet haben.

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

• CLDR-Daten enthalten jetzt ein "_iana"-Attribut, das den aktuellsten Identifier angibt, wenn der ältere, stabile Identifier umbenannt wurde. Browser können dieses neue Attribut verwenden, um Anrufern aktuelle Identifier bereitzustellen.
• Zeitzonen-Identifier, die vom Programmierer bereitgestellt werden, werden niemals durch einen Alias ersetzt. Zum Beispiel, wenn der Anrufer Asia/Calcutta oder Asia/Kolkata als Identifizierer-Eingabe für Temporal.ZonedDateTime.from() bereitstellt, dann wird im resultierenden Instanz-timeZoneId derselbe Identifizierer zurückgegeben. Beachten Sie, dass die Groß-/Kleinschreibung der Ausgaben normalisiert wird, um mit IANA übereinzustimmen, sodass ASIA/calCuTTa als Eingabe eine timeZoneId von Asia/Calcutta als Ausgabe erzeugt.
• Wenn ein Zeitzonen-Identifier nicht vom Anrufer bereitgestellt wird, sondern stattdessen vom System selbst bezogen wird (zum Beispiel, wenn Temporal.Now.timeZoneId() verwendet wird), werden moderne Identifier in allen Browsern zurückgegeben. Für Städte-Umbenennungen gibt es eine Verzögerung von zwei Jahren, bevor diese system-bereitgestellten Identifikatoren-APIs den neuen Namen anzeigen, 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 Zuweisung der primären Identifikatoren den Ländercode bewahrt: Zum Beispiel verzeichnet die IANA-Datenbank Atlantic/Reykjavik als Alias für Africa/Abidjan, aber weil sie unterschiedlichen Ländern (Island und Côte d'Ivoire bzw.) entsprechen, werden sie als verschiedene primäre Identifikatoren behandelt.

Diese Standardisierung gilt auch außerhalb von Temporal. Zum Beispiel, die timeZone-Option, die von Intl.DateTimeFormat.prototype.resolvedOptions() zurückgegeben wird, wird auch nie durch einen Alias ersetzt, obwohl Browser diese Identifikatoren traditionell vor der Standardisierung durch Temporal kanonisiert haben. Andererseits werden Intl.Locale.prototype.getTimeZones() und Intl.supportedValuesOf() (timeZone-Option) den aktuellsten Identifier zurückgeben, während einige Browser früher den alten, nicht primären Identifier zurückgegeben haben.

ZonedDateTime-Objekte können unter Verwendung des RFC 9557 Formats serialisiert und geparst werden, einer Erweiterung des ISO 8601 / RFC 3339 Formats. Der String hat folgendes Format (Leerzeichen sind nur zur Lesbarkeit hinzugefügt und sollten im eigentlichen String nicht vorhanden sein):

YYYY-MM-DD T HH:mm:ss.sssssssss Z/±HH:mm:ss.sssssssss [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 Datum-Uhrzeit-Separator, der T, t, oder ein Leerzeichen sein kann. Vorhanden, wenn und nur 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 , gefolgt sein und einer bis neun Stellen. Standard ist 00. Die HH, mm und ss Komponenten können durch : oder nichts getrennt werden. Sie können entweder nur ss weglassen oder sowohl ss als auch mm, sodass die Zeit eine von drei Formen haben kann: HH, HH:mm, oder HH:mm:ss.sssssssss.

Z/±HH:mm:ss.sssssssss Optional

Entweder der UTC-Indikator Z oder z, oder ein Offset von UTC in der Form + oder -, gefolgt vom gleichen Format wie die Zeitkomponente. Beachten Sie, dass Präzision auf Minutenbasis möglicherweise von anderen Systemen nicht unterstützt wird. Wenn weggelassen, wird das Offset aus dem Zeitzonen-Identifikator abgeleitet. Wenn vorhanden, dann muss die Zeit ebenfalls bereitgestellt werden. Z ist nicht dasselbe wie +00:00: Ersteres bedeutet, dass die Zeit in UTC-Form angegeben ist, unabhängig vom Zeitzonen-Identifier, während Letzteres bedeutet, dass die Zeit in lokaler Zeit angegeben ist, die zufällig UTC+0 ist, und wird über die offset-Option gegen den Zeitzonen-Identifier validiert.

[time_zone_id]

Ersetzen Sie time_zone_id durch den Zeitzonen-Identifier (benannt oder Offset) wie oben beschrieben. Kann ein Kritismus-Flag haben, indem der Identifier mit ! vorangestellt wird: z.B. [!America/New_York]. Dieses Flag weist andere Systeme im Allgemeinen darauf hin, dass es nicht ignoriert werden kann, wenn sie es nicht unterstützen. Beachten Sie, dass es für Temporal.ZonedDateTime.from() erforderlich ist: Wenn es weggelassen wird, wird ein RangeError ausgelöst. Wenn Sie ISO 8601 / RFC 3339 Strings ohne Zeitzonen-Identifikator-Anmerkungen parsen möchten, verwenden Sie Temporal.Instant.from() stattdessen.

[u-ca=calendar_id] Optional

Ersetzen Sie calendar_id durch den zu verwendenden Kalender. Kann ein Kritismus-Flag haben, indem der Schlüssel mit ! vorangestellt wird: z.B. [!u-ca=iso8601]. Dieses Flag weist andere Systeme im Allgemeinen darauf hin, 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. Der Standard ist [u-ca=iso8601]. Beachten Sie, dass das YYYY-MM-DD immer als ISO 8601 Kalenderdatum interpretiert und dann in den angegebenen Kalender konvertiert wird.

Als Eingabe werden andere Anmerkungen im [key=value]-Format ignoriert und dürfen das Kritismus-Flag nicht haben.

Beim Serialisieren können Sie die Bruchteilssekundenstellen, ob das Offset/Zeitzonen-ID/Kalender-ID angezeigt wird, und ob ein Kritismus-Flag für die Anmerkungen hinzugefügt wird, konfigurieren.

Angesichts einer Zeitzone ist die Umrechnung von UTC in lokale Zeit unkompliziert: Sie erhalten zuerst das Offset unter Verwendung des Zeitzonennamens und des Moments und addieren dann das Offset zum Moment. Das Gegenteil ist nicht wahr: Die Umrechnung von lokaler Zeit in UTC, ohne explizites Offset, ist mehrdeutig, weil eine lokale Zeit null, einer oder vielen UTC-Zeiten entsprechen kann. Betrachten Sie die häufigste Ursache: Übergänge zur Sommerzeit. Nehmen Sie New York als Beispiel. Sein Standard-Offset ist UTC-5, aber während der Sommerzeit werden alle Uhren um eine Stunde vorgestellt, sodass das Offset UTC-4 wird. In den USA finden die Übergänge um 2:00 Uhr Ortszeit statt, sodass diese beiden Übergangstage betrachtet werden sollten:

Wie Sie sehen können, verschwindet im März eine Stunde aus der lokalen Zeit, und im November gibt es zwei Stunden mit der gleichen Wand-Uhrzeit. Angenommen, wir haben ein PlainDateTime gespeichert, das "2024-03-10T02:05:00" sagt, und wir wollen es in der America/New_York Zeitzone interpretieren, es wird keine Zeit geben, die dem entspricht, während ein PlainDateTime, das "2024-11-03T01:05:00" sagt, zwei verschiedenen Momenten entsprechen kann.

Bei der Erstellung eines ZonedDateTime aus einer lokalen Zeit (mit Temporal.ZonedDateTime.from(), Temporal.ZonedDateTime.prototype.with(), Temporal.PlainDateTime.prototype.toZonedDateTime()) ist das Verhalten bei 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 um die Dauer der Lücke zurück.

later

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

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 eine Lücke gibt.

Es gibt mehrere Fälle, in denen es keine Mehrdeutigkeit bei der Erstellung eines ZonedDateTime gibt:

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

Wir haben bereits demonstriert, wie Mehrdeutigkeit entstehen kann, wenn man eine lokale Zeit in einer Zeitzone interpretiert, ohne ein explizites Offset anzugeben. Wenn Sie jedoch ein explizites Offset angeben, entsteht ein weiterer Konflikt: zwischen dem angegebenen Offset und dem berechneten Offset aus der Zeitzone und der lokalen Zeit. Dies ist ein unvermeidbares reales Problem: Wenn Sie eine Zeit in der Zukunft mit einem vorhergesagten Offset speichern, kann sich die Zeitzonendefinition ändern, bevor diese Zeit kommt, aufgrund politischer Gründe. Zum Beispiel, angenommen, wir setzen 2018 eine Erinnerung für die Zeit 2019-12-23T12:00:00-02:00[America/Sao_Paulo] (was eine Sommerzeit ist; Brasilien befindet sich auf der südlichen Hemisphäre, daher tritt die Sommerzeit im Oktober ein und endet im Februar). Aber bevor diese Zeit kommt, beschließt Brasilien Anfang 2019, die Sommerzeit nicht mehr zu beachten, sodass das tatsächliche Offset -03:00 wird. Sollte die Erinnerung jetzt noch um 12:00 Uhr ausgelöst werden (unter Beibehaltung der lokalen Zeit), oder sollte sie um 11:00 Uhr unter Beibehaltung der exakten Zeit ausgelöst werden?

Beim Erstellen eines ZonedDateTime mit Temporal.ZonedDateTime.from() oder beim Aktualisieren mit der with()-Methode ist das Verhalten bei Offset-Mehrdeutigkeit über die offset-Option konfigurierbar:

use

Verwenden Sie das Offset, um die genaue Zeit zu berechnen. Diese Option "verwendet" das Offset bei der Bestimmung des Moments, der durch den String repräsentiert wird, der derselbe Moment ist, der ursprünglich berechnet wurde, als wir die Zeit gespeichert haben, selbst wenn sich das Offset zu diesem Moment geändert hat. Der Zeitzonen-Identifier wird weiterhin verwendet, um das (möglicherweise aktualisierte) Offset zu ermitteln und dieses Offset zu verwenden, um die genaue Zeit in lokale Zeit umzuwandeln.

ignore

Verwenden Sie den Zeitzonen-Identifier, um das Offset erneut zu berechnen, wobei das im String angegebene Offset ignoriert wird. Diese Option behält die gleiche lokale Zeit bei, wie ursprünglich berechnet, als wir die Zeit gespeichert haben, kann aber einem anderen Moment entsprechen. Beachten Sie, dass diese Option dieselbe Mehrdeutigkeit der lokalen Zeitinterpretation verursachen kann, wie oben demonstriert, die mit der disambiguation-Option gelöst wird.

reject

Werfen Sie einen RangeError, wann immer es einen Konflikt zwischen dem Offset und dem Zeitzonen-Identifier gibt. Dies ist der Standard für Temporal.ZonedDateTime.from().

prefer

Verwenden Sie das Offset, wenn es gültig ist, andernfalls berechnen Sie das Offset aus dem Zeitzonen-Identifier. Dies ist der Standard für Temporal.ZonedDateTime.prototype.with() (siehe die Methode für weitere Details). Dies unterscheidet sich von ignore, weil im Fall von Mehrdeutigkeit der lokalen Zeit das Offset zur Lösung verwendet wird, anstatt der disambiguation-Option.

Beachten Sie, dass das Z Offset nicht +00:00 bedeutet; es wird immer unabhängig von der Zeitzone als gültig betrachtet. Die Zeit wird als UTC-Zeit interpretiert, und der Zeitzonen-Identifier wird dann verwendet, um sie in lokale Zeit zu konvertieren. Mit anderen Worten, Z erzwingt dasselbe Verhalten wie die ignore-Option, und seine Ergebnisse können niemals mehrdeutig sein.

Temporal.ZonedDateTime() Experimentell

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

Temporal.ZonedDateTime.compare() Experimentell

Gibt eine Zahl (-1, 0 oder 1) zurück, die angibt, ob die erste Datum-Uhrzeit vor, gleichzeitig oder nach der zweiten Datum-Uhrzeit kommt. Entspricht dem Vergleich der epochNanoseconds der beiden Datum-Uhrzeiten.

Temporal.ZonedDateTime.from() Experimentell

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

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

Temporal.ZonedDateTime.prototype.calendarId Experimentell

Gibt einen String zurück, der den Kalender repräsentiert, der verwendet wird, 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 Anfangswert die Temporal.ZonedDateTime()-Konstruktor.

Temporal.ZonedDateTime.prototype.day Experimentell

Gibt eine positive ganze Zahl zurück, die den 1-basierten Tag-Index im Monat dieses Datums darstellt, was dieselbe Tagesnummer ist, die Sie in einem Kalender sehen würden. Kalender-abhängig. Beginnt im Allgemeinen bei 1 und ist kontinuierlich, aber nicht immer.

Temporal.ZonedDateTime.prototype.dayOfWeek Experimentell

Gibt eine positive ganze Zahl zurück, die den 1-basierten Tag-Index in der Woche dieses Datums darstellt. Tage in einer Woche werden sequentiell von 1 bis daysInWeek nummeriert, wobei jede Zahl ihrem Namen zugeordnet wird. Kalender-abhängig. 1 stellt normalerweise Montag im Kalender dar, auch 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 Experimentell

Gibt eine positive ganze Zahl zurück, die den 1-basierten Tag-Index im Jahr dieses Datums darstellt. Der erste Tag dieses Jahres ist 1, und der letzte Tag ist der daysInYear. Kalender-abhängig.

Temporal.ZonedDateTime.prototype.daysInMonth Experimentell

Gibt eine positive ganze Zahl zurück, die die Anzahl der Tage im Monat dieses Datums darstellt. Kalender-abhängig.

Temporal.ZonedDateTime.prototype.daysInWeek Experimentell

Gibt eine positive ganze Zahl zurück, die die Anzahl der Tage in der Woche dieses Datums darstellt. Kalender-abhängig. Für den ISO 8601 Kalender sind es immer 7, aber in anderen Kalendersystemen kann es von Woche zu Woche unterschiedlich sein.

Temporal.ZonedDateTime.prototype.daysInYear Experimentell

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

Temporal.ZonedDateTime.prototype.epochMilliseconds Experimentell

Gibt eine ganze Zahl zurück, die die Anzahl der Millisekunden seit dem Unix-Epoch (Mitternacht am Anfang des 1. Januar 1970, UTC) bis zu diesem Moment darstellt. Entspricht der Teilung von epochNanoseconds durch 1e6 und dem Abrunden des Ergebnisses.

Temporal.ZonedDateTime.prototype.epochNanoseconds Experimentell

Gibt einen BigInt zurück, der die Anzahl der Nanosekunden seit dem Unix-Epoch (Mitternacht am Anfang des 1. Januar 1970, UTC) bis zu diesem Moment darstellt.

Temporal.ZonedDateTime.prototype.era Experimentell

Gibt einen kalender-spezifischen Kleinbuchstaben-String 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 die gleiche Weise wie year. Kalender-abhängig. Für Gregorianisch ist es entweder "gregory" oder "gregory-inverse".

Temporal.ZonedDateTime.prototype.eraYear Experimentell

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

Temporal.ZonedDateTime.prototype.hour Experimentell

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

Temporal.ZonedDateTime.prototype.hoursInDay Experimentell

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

Temporal.ZonedDateTime.prototype.inLeapYear Experimentell

Gibt einen boolean zurück, der angibt, ob dieses Datum in einem Schaltjahr liegt. Ein Schaltjahr ist ein Jahr mit mehr Tagen (aufgrund eines Schalttages oder -monats) als ein normales Jahr. Kalender-abhängig.

Temporal.ZonedDateTime.prototype.microsecond Experimentell

Gibt eine ganze Zahl von 0 bis 999 zurück, die die Mikrosekunden (10^-6 Sekunde) Komponente dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.millisecond Experimentell

Gibt eine ganze Zahl von 0 bis 999 zurück, die die Millisekunden (10^-3 Sekunde) Komponente dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.minute Experimentell

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

Temporal.ZonedDateTime.prototype.month Experimentell

Gibt eine positive ganze Zahl zurück, die den 1-basierten Monat-Index 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, kann der Monat mit dem gleichen monthCode unterschiedliche month-Indizes für verschiedene Jahre haben.

Temporal.ZonedDateTime.prototype.monthCode Experimentell

Gibt einen kalender-spezifischen String zurück, der den Monat dieses Datums darstellt. Kalender-abhängig. In der Regel ist es M plus eine zweistellige Monatsnummer. Für Schaltmonate ist es der vorherige Monatscode gefolgt von L. Falls der Schaltmonat der erste Monat des Jahres ist, ist der Code M00L.

Temporal.ZonedDateTime.prototype.monthsInYear Experimentell

Gibt eine positive ganze Zahl 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 abweichen.

Temporal.ZonedDateTime.prototype.nanosecond Experimentell

Gibt eine ganze Zahl von 0 bis 999 zurück, die die Nanosekunden (10^-9 Sekunde) Komponente dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.offset Experimentell

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

Temporal.ZonedDateTime.prototype.offsetNanoseconds Experimentell

Gibt eine ganze Zahl zurück, die das Offset verwendet, um den internen Moment zu interpretieren, als eine Anzahl von Nanosekunden (positiv oder negativ).

Temporal.ZonedDateTime.prototype.second Experimentell

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

Temporal.ZonedDateTime.prototype.timeZoneId Experimentell

Gibt einen String zurück, der den Zeitzonen-Identifier verwendet, um den internen Moment zu interpretieren. Es verwendet den gleichen String, der bei der Erstellung des Temporal.ZonedDateTime-Objekts verwendet wurde, welcher entweder ein IANA-Zeitzonenname oder ein festes Offset ist.

Temporal.ZonedDateTime.prototype.weekOfYear Experimentell

Gibt eine positive ganze Zahl zurück, die den 1-basierten Wochen-Index 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 vorherigen Jahres oder der ersten Woche des nächsten Jahres zugeschrieben werden können.

Temporal.ZonedDateTime.prototype.year Experimentell

Gibt eine ganze Zahl zurück, die die Anzahl der Jahre dieses Datums relativ zum Beginn eines kalender-spezifischen Epoch-Jahres darstellt. Kalender-abhängig. Normalerweise ist Jahr 1 entweder das erste Jahr der letzten Ära oder das ISO 8601 Jahr 0001. Wenn die Epoche in der Jahresmitte ist, wird dieses Jahr den gleichen Wert vor und nach dem Startdatum der Ära haben.

Temporal.ZonedDateTime.prototype.yearOfWeek Experimentell

Gibt eine ganze Zahl zurück, die das Jahr angibt, das mit der weekOfYear dieses Datums paarig ist, 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 vorherigen Jahres oder der ersten Woche des nächsten Jahres zugeschrieben werden, was dazu führt, dass sich das yearOfWeek um 1 unterscheidet.

Temporal.ZonedDateTime.prototype[Symbol.toStringTag]

Der Anfangswert der [Symbol.toStringTag] Eigenschaft ist der String "Temporal.ZonedDateTime". Diese Eigenschaft wird in Object.prototype.toString() verwendet.

Temporal.ZonedDateTime.prototype.add() Experimentell

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diesen Datum-Uhrzeit um eine angegebene Dauer (in einer Form konvertierbar von Temporal.Duration.from()) nach vorne verschoben darstellt.

Temporal.ZonedDateTime.prototype.equals() Experimentell

Gibt true zurück, wenn diese Datum-Uhrzeit im Wert mit einer anderen Datum-Uhrzeit gleichwertig ist (in einer Form konvertierbar von Temporal.ZonedDateTime.from()), und false sonst. Sie werden sowohl nach ihren Moment-Werten, Zeitzonen und ihren Kalendern verglichen, sodass zwei Datum-Uhrzeiten aus verschiedenen Kalendern oder Zeitzonen als gleich von Temporal.ZonedDateTime.compare() betrachtet werden können, aber nicht von equals().

Temporal.ZonedDateTime.prototype.getTimeZoneTransition() Experimentell

Gibt ein Temporal.ZonedDateTime-Objekt zurück, das den ersten Moment nach oder vor diesem Moment darstellt, bei dem sich das 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() Experimentell

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

Temporal.ZonedDateTime.prototype.since() Experimentell

Gibt ein neues Temporal.Duration-Objekt zurück, das die Dauer von einer anderen Datum-Uhrzeit (in einer Form konvertierbar von Temporal.ZonedDateTime.from()) zu dieser Datum-Uhrzeit darstellt. Die Dauer ist positiv, wenn die andere Datum-Uhrzeit vor dieser Datum-Uhrzeit ist, und negativ, wenn danach.

Temporal.ZonedDateTime.prototype.startOfDay() Experimentell

Gibt ein Temporal.ZonedDateTime-Objekt zurück, das den ersten Moment dieses Datums in der Zeitzone darstellt. Es hat normalerweise eine Uhrzeit von 00:00:00, kann aber anders sein, wenn Mitternacht aufgrund von Offset-Änderungen nicht existiert, in diesem Fall wird die der erste existierende Zeitpunkt zurückgegeben.

Temporal.ZonedDateTime.prototype.subtract() Experimentell

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diesen Datum-Uhrzeit um eine angegebene Dauer (in einer Form konvertierbar von Temporal.Duration.from()) zurückwärts verschoben darstellt.

Temporal.ZonedDateTime.prototype.toInstant() Experimentell

Gibt ein neues Temporal.Instant-Objekt zurück, das den Moment dieser Datum-Uhrzeit darstellt.

Temporal.ZonedDateTime.prototype.toJSON() Experimentell

Gibt einen String zurück, der diesen Datum-Uhrzeit in demselben RFC 9557 Format wie der Aufruf von toString() darstellt. Soll implizit durch JSON.stringify() aufgerufen werden.

Temporal.ZonedDateTime.prototype.toLocaleString() Experimentell

Gibt einen String mit einer sprachspezifischen Darstellung dieser Datum-Uhrzeit zurück.

Temporal.ZonedDateTime.prototype.toPlainDate() Experimentell

Gibt ein neues Temporal.PlainDate-Objekt zurück, das das Datumsstück dieser Datum-Uhrzeit darstellt.

Temporal.ZonedDateTime.prototype.toPlainDateTime() Experimentell

Gibt ein neues Temporal.PlainDateTime-Objekt zurück, das das Datums- und Uhrzeitstück dieser Datum-Uhrzeit darstellt. Nur die Zeitzoneninformationen werden entfernt.

Temporal.ZonedDateTime.prototype.toPlainTime() Experimentell

Gibt ein neues Temporal.PlainTime-Objekt zurück, das das Uhrzeitstück dieser Datum-Uhrzeit darstellt.

Temporal.ZonedDateTime.prototype.toString() Experimentell

Gibt einen String zurück, der diese Datum-Uhrzeit im RFC 9557 Format darstellt.

Temporal.ZonedDateTime.prototype.until() Experimentell

Gibt ein neues Temporal.Duration-Objekt zurück, das die Dauer von dieser Datum-Uhrzeit zu einer anderen Datum-Uhrzeit (in einer Form konvertierbar von Temporal.ZonedDateTime.from()) darstellt. Die Dauer ist positiv, wenn die andere Datum-Uhrzeit nach dieser Datum-Uhrzeit liegt, und negativ, wenn davor.

Temporal.ZonedDateTime.prototype.valueOf() Experimentell

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

Temporal.ZonedDateTime.prototype.with() Experimentell

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

Temporal.ZonedDateTime.prototype.withCalendar() Experimentell

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

Temporal.ZonedDateTime.prototype.withPlainTime() Experimentell

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diesen Datum-Uhrzeit mit dem Zeitteil vollständig durch die neue Zeit ersetzt darstellt (in einer Form konvertierbar von Temporal.PlainTime.from())

Temporal.ZonedDateTime.prototype.withTimeZone() Experimentell

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

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