Temporal.ZonedDateTime

Beschreibung

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

ZonedDateTime ist die einzige Temporal-Klasse, die zeitzonenbewusst ist. Die Hinzufügung einer Zeitzone führt dazu, dass ZonedDateTime-Objekte wichtiges abweichendes Verhalten im Vergleich zu Temporal.PlainDateTime-Objekten aufweisen. Nämlich, dass Sie nicht mehr davon ausgehen können "die Zeit 1 Minute später" sei jeden Tag gleich oder dass ein Tag 24 Stunden hat. Im schlimmsten Fall könnte 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 fortschreitet, während die physische Zeit voranschreitet. Im Gegensatz dazu sind Benutzer mehr an ihrer lokalen Zeit interessiert, das ist die Zeit, die sie auf ihren Kalendern und Uhren ablesen. Der Prozess der Umwandlung zwischen UTC-Zeit und lokaler Zeit beinhaltet ein Zeitzonen-Offset, der berechnet wird als:

local time = UTC time + offset

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

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

Indem man diese lokale Zeit mit dem Offset versieht, und sie so als "1969-12-31T19:00:00-05:00" ausdrückt, kann sie nun zweifelsfrei 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 zu allen Zeiten der gleiche Offset verwendet wird. Zwei Uhren in derselben Zeitzone zeigen immer gleichzeitig die gleiche Zeit an, aber der Offset ist nicht unbedingt konstant: das heißt, diese Uhrenzeiten können abrupt wechseln. Dies geschieht häufig während der Zeitumstellung auf Sommer- oder Winterzeit, bei der sich der Offset um eine Stunde ändert, was zweimal im Jahr passiert. Offsets können sich auch dauerhaft aufgrund politischer Änderungen ändern, z. B. wenn ein Land die Zeitzone wechselt.

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

• Einen primären Zeitzonen-Identifikator, der die Zeitzone eindeutig identifiziert. Sie bezieht sich normalerweise auf ein geografisches Gebiet, das von einer 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 (die aus historischen Gründen ein negativer Offset -05:00 ist) bezeichnen. Aus historischen Gründen ist der primäre Name für die UTC-Zeitzone UTC, obwohl sie in IANA Etc/UTC ist.
• Eine Zeitzonendefinition in Form einer Tabelle, die UTC-Datum/Zeitbereiche (einschließlich zukünftiger Bereiche) bestimmten Offsets zuordnet.
• Null oder mehr nicht primäre Zeitzonen-Identifikatoren, die Aliase für den primären Zeitzonen-Identifikator sind. Dies sind normalerweise historische Namen, die nicht mehr verwendet werden, jedoch aus Kompatibilitätsgründen erhalten bleiben. Weitere Informationen finden Sie unten.

Als Input werden benannte Identifikatoren ohne Berücksichtigung der Groß- und Kleinschreibung abgeglichen. Intern werden sie in der bevorzugten Schreibweise gespeichert, und nicht primäre Identifikatoren werden nicht zu ihrem primären Identifikator konvertiert.

Wenn eine Temporal-API einen Zeitzonen-Identifikator akzeptiert, werden neben primären und nicht primären Zeitzonen-Identifikatoren auch ein Offset-Zeitzonen-Identifikator akzeptiert, der in derselben Form wie das Offset ist, ausgenommen Unterminuten-Genauigkeit ist nicht erlaubt. Zum Beispiel sind +05:30, -08, +0600 alles gültige Offset-Identifikatoren. Intern werden Offset-Identifikatoren in der ±HH:mm-Form gespeichert.

Aus Bequemlichkeitsgründen können Sie beim Bereitstellen eines Zeitzonen-Identifikators für Temporal-APIs wie Temporal.ZonedDateTime.prototype.withTimeZone() und die timeZoneId-Option von Temporal.ZonedDateTime.from() dies in einigen anderen Formen tun:

• Als eine andere ZonedDateTime-Instanz, deren timeZoneId verwendet wird.
• Als ein RFC 9557 String mit einer Zeitzonen-Annotation, deren Zeitzonen-Identifikator verwendet wird.
• Als ein ISO 8601 / RFC 3339 String, der ein Offset enthält, dessen Offset als ein Offset-Identifikator verwendet wird; oder bei Verwendung von Z, dann wird die "UTC"-Zeitzone 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 wie den Beginn oder das Ende der Sommerzeit abzuleiten. Stattdessen sollten Sie in Erwägung ziehen, 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 angesichts politischer Veränderungen hinzuzufügen. In seltenen Fällen werden IANA-Zeitzonen-Identifikatoren jedoch umbenannt, um aktualisierte englische Übersetzungen eines Stadtnamens zu übernehmen oder 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 Bibliothek, auf die sich Browser verlassen, um Zeitzonen-Identifikatoren und Daten bereitzustellen) die Umbenennung von IANA aus Stabilitätsgründen nicht übernommen hat. Infolgedessen meldeten einige Browser wie Chrome und Safari die veralteten Identifikatoren von CLDR, während andere Browser wie Firefox die Standardwerte von CLDR überschrieben und die aktuellen Primär-Identifikatoren meldeten.

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

• CLDR-Daten enthält jetzt ein "_iana" Attribut, das den aktuellsten Identifikator angibt, falls der ältere, stabile Identifikator umbenannt wurde. Browser können dieses neue Attribut verwenden, um Anrufern die aktuellsten Identifikatoren bereitzustellen.
• Zeitzonen-Identifikatoren, die vom Programmierer bereitgestellt werden, werden niemals durch einen Alias ersetzt. Zum Beispiel, wenn der Anrufer Asia/Calcutta oder Asia/Kolkata als Identifikator-Input für Temporal.ZonedDateTime.from() bereitstellt, dann wird derselbe Identifikator in der resultierenden Instanz timeZoneId zurückgegeben. Beachten Sie, dass die Schreibweise von Ausgaben normalisiert wird, um mit IANA übereinzustimmen, sodass ASIA/calCuTTa als Input eine timeZoneId von Asia/Calcutta als Ausgabe erzeugt.
• Wenn ein Zeitzonen-Identifikator nicht von einem Anrufer bereitgestellt, sondern stattdessen aus dem System selbst bezogen wird (z. B. bei Verwendung von Temporal.Now.timeZoneId()), werden moderne Identifikatoren in allen Browsern zurückgegeben. Bei Stadtnamenänderungen gibt es eine zweijährige Verzögerung, bevor diese systembasierten Identifikatoren-APIs den neuen Namen zurückgeben, 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 Identifikatoren den Ländercode beibehält: zum Beispiel zeichnet die IANA-Datenbank Atlantic/Reykjavik als Alias für Africa/Abidjan auf, aber da sie zu unterschiedlichen Ländern gehören (Island und Côte d'Ivoire), werden sie als unterschiedliche primäre Identifikatoren behandelt.

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

RFC 9557-Format

ZonedDateTime-Objekte können mithilfe des RFC 9557-Formats, einer Erweiterung des ISO 8601 / RFC 3339-Formats, serialisiert und geparst werden. Der String hat die folgende Form (Leerzeichen sind nur zur Leserlichkeit 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 - Vorzeichen.

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 gar nichts getrennt werden.

T Optional

Der datumszeitliche Separator, der T, t oder ein Leerzeichen sein kann. Nur vorhanden, wenn HH vorhanden ist.

HH Optional

Eine zweistellige Zahl von 00 bis 23. Standardmäßig 00.

mm Optional

Eine zweistellige Zahl von 00 bis 59. Standardmäßig 00.

ss.sssssssss Optional

Eine zweistellige Zahl von 00 bis 59. Kann optional durch einen . oder , gefolgt von einer bis neun Ziffern ergänzt werden. Standardmäßig 00. Die HH, mm und ss Komponenten können durch : oder gar nichts getrennt werden. Sie können entweder nur ss oder sowohl ss als auch mm weglassen, so dass die Zeit in einer von drei Formen erscheinen kann: HH, HH:mm, oder HH:mm:ss.sssssssss.

Z/±HH:mm Optional

Entweder der UTC-Designator Z oder z oder ein Offset von UTC in der Form + oder - gefolgt von demselben Format wie die Zeitkomponente. Beachten Sie, dass Unterminuten-Genauigkeit (:ss.sssssssss) von anderen Systemen möglicherweise nicht unterstützt wird und akzeptiert, aber nie ausgegeben wird. Wenn es weggelassen wird, wird das Offset vom Zeitzonen-Identifikator abgeleitet. Wenn vorhanden, muss auch die Zeit angegeben werden. Z ist nicht dasselbe wie +00:00: das erste bedeutet, dass die Zeit in UTC-Form festgelegt ist, unabhängig vom Zeitzonen-Identifikator, während das zweite bedeutet, dass die Zeit in Ortszeit angegeben ist, die zufällig UTC+0 entspricht, und wird gegen den Zeitzonen-Identifikator über die offset Option validiert.

[time_zone_id]

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

[u-ca=calendar_id] Optional

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

Als Input werden andere Annotationen im [key=value]-Format ignoriert, und sie dürfen nicht das kritische Flag haben.

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

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

Gibt man eine Zeitzone an, ist die Umwandlung von UTC zur lokalen Zeit unkompliziert: Sie erhalten zuerst das Offset anhand des Zeitzonennamens und des Moments und addieren dann das Offset zum Moment. Umgekehrt gilt dies nicht: Die Umwandlung von lokaler Zeit in UTC-Zeit ohne explizites Offset ist mehrdeutig, da eine lokale Zeit null, einer oder mehreren UTC-Zeiten entsprechen kann. Betrachten Sie die häufigste Ursache: Zeitumstellungen. 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 der Offset zu UTC-4 wird. In den USA finden die Übergänge um 2:00 Uhr Ortszeit statt, beachten Sie diese beiden Übergangstage:

Wie Sie sehen können, verschwand im März eine Stunde aus der lokalen Zeit, und im November haben wir zwei Stunden, die dieselbe Uhrzeit haben. Angenommen, wir haben einen PlainDateTime gespeichert, der sagt "2024-03-10T02:05:00", und wir möchten ihn in der America/New_York-Zeitzone interpretieren, gibt es keine Zeit, die ihm entspricht, während ein PlainDateTime, der sagt "2024-11-03T01:05:00" zwei verschiedenen Momenten entsprechen kann.

Beim Erstellen eines ZonedDateTime aus einer lokalen Zeit (mit Temporal.ZonedDateTime.from(), Temporal.ZonedDateTime.prototype.with(), Temporal.PlainDateTime.prototype.toZonedDateTime()), ist das Verhalten bei Uneindeutigkeit und Lücken mit der 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 Lückendauer.

later

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

compatible (Standard)

Gleiches Verhalten wie Date: verwenden Sie later bei Lücken und earlier bei Uneindeutigkeiten.

reject

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

Es gibt mehrere Fälle, in denen beim Erstellen eines ZonedDateTime keine Uneindeutigkeit besteht:

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

Offset-Uneindeutigkeit

Wir haben bereits gezeigt, wie Uneindeutigkeit entstehen kann, wenn eine lokale Zeit in einer Zeitzone ohne explizites Offset interpretiert wird. Wenn jedoch ein explizites Offset bereitgestellt wird, entsteht ein weiterer Konflikt: zwischen dem angegebenen Offset und dem aus der Zeitzone und der lokalen Zeit berechneten Offset. Dies ist ein unvermeidbares Problem in der realen Welt: Wenn Sie eine Zeit in der Zukunft mit einem erwarteten Offset speichern, kann die Zeitzonendefinition vor dieser Zeit aufgrund politischer Gründe geändert werden. Zum Beispiel, angenommen, wir stellen 2018 eine Erinnerung auf die Zeit 2019-12-23T12:00:00-02:00[America/Sao_Paulo] ein (was in der Sommerzeit liegt; Brasilien befindet sich auf der Südhalbkugel, somit beginnt die Sommerzeit im Oktober und endet im Februar). Aber bevor diese Zeit kommt, beschließt Brasilien Anfang 2019, nicht mehr die Sommerzeit zu beobachten, daher wird der tatsächliche Offset -03:00. Sollte die Erinnerung nun immer noch um Mittag ausgelöst werden (indem die lokale Zeit beibehalten wird), oder sollte sie um 11:00 Uhr ausgelöst werden (indem die genaue Zeit beibehalten wird)?

Beim Erstellen eines ZonedDateTime mit Temporal.ZonedDateTime.from() oder bei dessen Aktualisierung mit der with()-Methode ist das Verhalten bei Offset-Uneindeutigkeit mit der offset-Option konfigurierbar:

use

Verwenden Sie das Offset, um die genaue Zeit zu berechnen. Diese Option "verwendet" das Offset, um den durch den String dargestellten Moment zu bestimmen, der derselbe ursprünglich berechnete Moment sein wird, als wir die Zeit gespeichert haben, selbst wenn das Offset zu diesem Moment geändert wurde. Der Zeitzonen-Identifikator wird noch verwendet, um das (möglicherweise aktualisierte) Offset zu erschließen und dieses Offset zu verwenden, um die genaue Zeit in lokale Zeit umzuwandeln.

ignore

Verwenden Sie den Zeitzonen-Identifikator, um das Offset neu zu berechnen, ignorieren Sie das im String angegebene Offset. Diese Option behält dieselbe lokale Zeit bei, die ursprünglich berechnet wurde, als wir die Zeit gespeichert haben, kann aber einem anderen Moment entsprechen. Beachten Sie, dass diese Option dieselbe lokale Zeitinterpretations-Umschließung wie oben gezeigt verursachen kann, die mit der disambiguation-Option aufgelöst wird.

reject

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

prefer

Verwenden Sie das Offset, wenn es gültig ist, berechnen Sie es ansonsten aus dem Zeitzonen-Identifikator. Dies ist der Standard für Temporal.ZonedDateTime.prototype.with() (siehe die Methode für mehr Details). Dies unterscheidet sich von ignore, da im Fall eines lokalen Zeituneindeutigkeit das Offset verwendet wird, um es zu lösen, und nicht die disambiguation-Option.

Beachten Sie, dass das Z-Offset nicht gleich +00:00 ist. Das Z-Offset bedeutet "die Zeit in UTC ist bekannt, aber der Offset zur Ortszeit ist unbekannt", gemäß RFC 9557. Wenn der Zeitstring das Z-Offset verwendet, wird die offset-Option ignoriert, und das Offset wird aus der Zeitzonen-ID abgeleitet. Andererseits wird das +00:00-Offset als ein lokales Zeitoffset interpretiert, das zufällig UTC entspricht und gegen die Zeitzonen-ID validiert wird.

Konstruktor

Temporal.ZonedDateTime() Experimentell

Erstellt ein neues Temporal.ZonedDateTime-Objekt, indem die zugrunde liegenden Daten direkt bereitgestellt werden.

Statische Methoden

Temporal.ZonedDateTime.compare() Experimentell

Gibt eine Zahl (-1, 0 oder 1) zurück, die angibt, ob das erste Datum-Uhrzeit vor, gleich oder nach dem zweiten Datum-Uhrzeit kommt. Entspricht dem Vergleichen 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.

Instanz-Eigenschaften

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 für die Interpretation des internen ISO 8601-Datums verwendet wird.

Temporal.ZonedDateTime.prototype.constructor

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

Temporal.ZonedDateTime.prototype.day Experimentell

Gibt eine positive Ganzzahl zurück, die den 1-basierten Tagesindex im Monat dieses Datums darstellt, was die gleiche Tageszahl ist, die Sie auf 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 Ganzzahl zurück, die den 1-basierten Tagesindex in der Woche dieses Datums darstellt. Tage in einer Woche sind sequentiell von 1 bis daysInWeek nummeriert, wobei jede Zahl ihrem Namen zugeordnet ist. Kalender-abhängig. 1 repräsentiert normalerweise Montag im Kalender, selbst wenn Orte, die den Kalender verwenden, einen anderen Tag als ersten Tag der Woche betrachten können (siehe Intl.Locale.prototype.getWeekInfo()).

Temporal.ZonedDateTime.prototype.dayOfYear Experimentell

Gibt eine positive Ganzzahl zurück, die den 1-basierten Tagesindex 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 Ganzzahl zurück, die die Anzahl der Tage im Monat dieses Datums darstellt. Kalender-abhängig.

Temporal.ZonedDateTime.prototype.daysInWeek Experimentell

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

Temporal.ZonedDateTime.prototype.daysInYear Experimentell

Gibt eine positive Ganzzahl 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 Ganzzahl zurück, die die Anzahl der Millisekunden angibt, die seit dem Unix-Epoch (Mitternacht zu Beginn des 1. Januar 1970, UTC) bis zu diesem Moment vergangen sind. Entspricht der Division von epochNanoseconds durch 1e6 und der Rundung nach unten des Ergebnisses.

Temporal.ZonedDateTime.prototype.epochNanoseconds Experimentell

Gibt eine BigInt zurück, die die Anzahl der Nanosekunden angibt, die seit dem Unix-Epoch (Mitternacht zu Beginn des 1. Januar 1970, UTC) bis zu diesem Moment vergangen sind.

Temporal.ZonedDateTime.prototype.era Experimentell

Gibt einen kalenderabhängigen Kleinbuchstaben-String zurück, der die Epoche dieses Datums darstellt, oder undefined, wenn der Kalender keine Epochen verwendet (z.B. ISO 8601). era und eraYear identifizieren zusammen ein Jahr in einem Kalender eindeutig, genauso wie es year tut. Kalender-abhängig. Für den gregorianischen Kalender ist es entweder "gregory" oder "gregory-inverse".

Temporal.ZonedDateTime.prototype.eraYear Experimentell

Gibt eine nichtnegative Ganzzahl zurück, die das Jahr dieses Datums innerhalb der Epoche darstellt, oder undefined, wenn der Kalender keine Epochen verwendet (z.B. ISO 8601). Der Jahr-Index beginnt normalerweise bei 1 (häufiger) oder 0, und Jahre in einer Epoche können mit der Zeit abnehmen (z.B. gregorianisches BCE). era und eraYear identifizieren zusammen ein Jahr in einem Kalender eindeutig, genauso wie year es tut. Kalender-abhängig.

Temporal.ZonedDateTime.prototype.hour Experimentell

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

Temporal.ZonedDateTime.prototype.hoursInDay Experimentell

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

Temporal.ZonedDateTime.prototype.inLeapYear Experimentell

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

Temporal.ZonedDateTime.prototype.microsecond Experimentell

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

Temporal.ZonedDateTime.prototype.millisecond Experimentell

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

Temporal.ZonedDateTime.prototype.minute Experimentell

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

Temporal.ZonedDateTime.prototype.month Experimentell

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 der Index im Gegensatz zu Date.prototype.getMonth() 1-basiert ist. Wenn der Kalender Schaltmonate hat, dann kann der Monat mit demselben monthCode unterschiedliche month-Indizes für verschiedene Jahre haben.

Temporal.ZonedDateTime.prototype.monthCode Experimentell

Gibt einen kalenderabhängigen String zurück, der den Monat dieses Datums darstellt. Kalender-abhängig. Normalerweise ist es M plus eine zweistellige Monatszahl. Für Schaltmonate ist es der Code vom vorhergehenden Monat gefolgt von L. Wenn der Schaltmonat der erste Monat des Jahres ist, ist der Code M00L.

Temporal.ZonedDateTime.prototype.monthsInYear Experimentell

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 Experimentell

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

Temporal.ZonedDateTime.prototype.offset Experimentell

Gibt einen String zurück, der das Offset darstellt, das zur Interpretation des internen Moments verwendet wird, in der Form ±HH:mm (oder ±HH:mm:ss.sssssssss mit so viel Unterminuten-Genauigkeit wie nötig).

Temporal.ZonedDateTime.prototype.offsetNanoseconds Experimentell

Gibt eine Ganzzahl zurück, die das Offset darstellt, das zur Interpretation des internen Moments verwendet wird, als Anzahl der Nanosekunden (positiv oder negativ).

Temporal.ZonedDateTime.prototype.second Experimentell

Gibt eine Ganzzahl 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-Identifikator darstellt, der zur Interpretation des internen Moments verwendet wird. Es verwendet den gleichen String, der bei der Konstruktion des Temporal.ZonedDateTime-Objekts verwendet wurde, welcher entweder ein IANA-Zeitzonenname oder ein fester Offset ist.

Temporal.ZonedDateTime.prototype.weekOfYear Experimentell

Gibt eine positive Ganzzahl zurück, die den 1-basierten Wochenindex im yearOfWeek dieses Datums darstellt, oder undefined, wenn der Kalender kein wohldefiniertes 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 zugeordnet werden können.

Temporal.ZonedDateTime.prototype.year Experimentell

Gibt eine Ganzzahl zurück, die die Anzahl der Jahre dieses Datums relativ zum Beginn eines kalender-spezifischen Epoche-Jahres darstellt. Kalender-abhängig. Normalerweise ist Jahr 1 entweder das erste Jahr der letzten Epoche oder das ISO 8601 Jahr 0001. Wenn der Epochenbeginn in der Mitte des Jahres liegt, hat dieses Jahr denselben Wert vor und nach dem Startdatum der Epoche.

Temporal.ZonedDateTime.prototype.yearOfWeek Experimentell

Gibt eine Ganzzahl zurück, die das Jahr darstellt, das mit der weekOfYear dieses Datums gepaart werden soll, oder undefined, wenn der Kalender kein wohldefiniertes 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 zugeordnet werden, wodurch sich 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.

Instanz-Methoden

Temporal.ZonedDateTime.prototype.add() Experimentell

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

Temporal.ZonedDateTime.prototype.equals() Experimentell

Gibt true zurück, wenn diese Datum-Uhrzeit gleichwertig im Wert mit einer anderen Datum-Uhrzeit ist (in einer Form, die von Temporal.ZonedDateTime.from() konvertierbar ist), und false andernfalls. Sie werden sowohl nach ihren Momentwerten, Zeitzonen als auch ihren Kalendern verglichen, sodass zwei Datum-Uhrzeiten aus verschiedenen Kalendern oder Zeitzonen von Temporal.ZonedDateTime.compare() als gleich angesehen 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 repräsentiert, 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 Muster für Sommerzeit.

Temporal.ZonedDateTime.prototype.round() Experimentell

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diese 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, die von Temporal.ZonedDateTime.from() konvertierbar ist) zu dieser Datum-Uhrzeit darstellt. Die Dauer ist positiv, wenn die andere Datum-Uhrzeit vor dieser Datum-Uhrzeit ist und negativ, wenn sie nachher ist.

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 Zeit von 00:00:00, kann jedoch abweichen, wenn die Mitternacht aufgrund von Offset-Änderungen nicht existiert, in diesem Fall wird die erste existierende Zeit zurückgegeben.

Temporal.ZonedDateTime.prototype.subtract() Experimentell

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

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 diese Datum-Uhrzeit in demselben RFC 9557-Format wie der Aufruf von toString() darstellt. Soll implizit von JSON.stringify() aufgerufen werden.

Temporal.ZonedDateTime.prototype.toLocaleString() Experimentell

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

Temporal.ZonedDateTime.prototype.toPlainDate() Experimentell

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

Temporal.ZonedDateTime.prototype.toPlainDateTime() Experimentell

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

Temporal.ZonedDateTime.prototype.toPlainTime() Experimentell

Gibt ein neues Temporal.PlainTime-Objekt zurück, das den Zeitteil 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, die von Temporal.ZonedDateTime.from() konvertierbar ist) darstellt. Die Dauer ist positiv, wenn die andere Datum-Uhrzeit nach dieser Datum-Uhrzeit ist und negativ, wenn sie vorher ist.

Temporal.ZonedDateTime.prototype.valueOf() Experimentell

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

Temporal.ZonedDateTime.prototype.with() Experimentell

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

Temporal.ZonedDateTime.prototype.withCalendar() Experimentell

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

Temporal.ZonedDateTime.prototype.withPlainTime() Experimentell

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

Temporal.ZonedDateTime.prototype.withTimeZone() Experimentell

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

Spezifikationen

Browser-Kompatibilität

Siehe auch

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