Temporal.ZonedDateTime
Limited availability
This feature is not Baseline because it does not work in some of the most widely-used browsers.
Experimentell: Dies ist eine experimentelle Technologie
Überprüfen Sie die Browser-Kompatibilitätstabelle sorgfältig vor der Verwendung auf produktiven Webseiten.
Das Temporal.ZonedDateTime
Objekt repräsentiert ein Datum und eine Uhrzeit mit einer Zeitzone. Es wird grundsätzlich als Kombination aus einem instant, einer Zeitzone und einem Kalendersystem dargestellt.
Beschreibung
Ein ZonedDateTime
fungiert als Brücke zwischen einer exakten Zeit und einer Uhrzeit: Es stellt gleichzeitig einen Moment in der Geschichte dar (wie ein Temporal.Instant
) und eine lokale, auf dem Kalender basierende Zeit (wie ein Temporal.PlainDateTime
). Dies geschieht, indem das Instant, die Zeitzone und das Kalendersystem gespeichert werden. Die Zeitzone wird verwendet, um zwischen dem Instant 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 bringt bedeutende Verhaltensunterschiede der ZonedDateTime
Objekte gegenüber Temporal.PlainDateTime
Objekten mit sich. Namentlich können Sie nicht mehr davon ausgehen, dass "die Zeit 1 Minute später" an jedem Tag gleich ist, 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 Umstellung zwischen UTC-Zeit und lokaler Zeit beeinflussen.
Zeitzonen und Offsets
Alle Zeiten in JavaScript haben einen goldenen Standard: die UTC-Zeit, die sich kontinuierlich und gleichmäßig mit dem Fortschreiten der physischen Zeit erhöht. Im Gegensatz dazu interessieren sich Benutzer mehr für ihre lokale Zeit, die Zeit, die sie auf ihren Kalendern und Uhren sehen. Der Prozess der Umrechnung zwischen UTC-Zeit und lokaler Zeit umfasst 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" ist, dann ist die lokale Zeit:
1970-01-01T00:00:00 + -05:00 = 1969-12-31T19:00:00
Indem Sie diese lokale Zeit mit dem Offset nachstellen, und diese Zeit als "1969-12-31T19:00:00-05:00" ausdrücken, kann sie jetzt 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 zu allen Zeiten derselbe Offset verwendet wird. Zwei Uhren in derselben Zeitzone zeigen immer gleichzeitig die gleiche Zeit, aber der Offset ist nicht unbedingt konstant: Das heißt, die Zeiten dieser Uhren können sich abrupt ändern. Dies geschieht häufig während der Sommerzeitumstellungen, bei denen der Offset um eine Stunde geändert wird, was zweimal im Jahr passiert. Offsets können sich auch dauerhaft durch politische Änderungen ändern, z.B. ein Land wechselt die Zeitzone.
Die Zeitzonen sind in der IANA Time Zone Database gespeichert. Jede IANA-Zeitzone hat:
- Einen primären Zeitzonen-Identifier, der die Zeitzone eindeutig identifiziert. Er bezieht sich normalerweise auf ein geografisches Gebiet, das von einer Stadt verankert wird (z.B.
Europe/Paris
oderAfrica/Kampala
), kann aber auch Zeitzonen mit einem einzigen Offset wieUTC
(ein konsistenter+00:00
Offset) oderEtc/GMT+5
(was aus historischen Gründen ein negativer Offset-05:00
ist) bezeichnen. Aus historischen Gründen ist der primäre Name für die UTC-ZeitzoneUTC
, obwohl er in IANAEtc/UTC
ist. - Eine Zeitzonendefinition in Form einer Tabelle, die UTC-Datums-/Zeitbereiche (einschließlich zukünftiger Bereiche) auf spezifische Offsets abbildet.
- Null oder mehr nicht-primäre Zeitzonen-Identifier, die Aliase für den primären Zeitzonen-Identifier sind. Diese sind normalerweise historische Namen, die nicht mehr verwendet werden, aber aus Kompatibilitätsgründen erhalten bleiben. Siehe unten für weitere Informationen.
Als Eingabe werden benannte Bezeichnungen fallunempfindlich abgeglichen. Intern werden sie in ihrer bevorzugten Schreibweise gespeichert, und nicht-primäre Bezeichnungen werden nicht in ihre primäre Bezeichnung umgewandelt.
Hinweis:
Wenn Sie den Zeitzonennamen festlegen, möchten Sie ihn selten auf "UTC"
setzen. ZonedDateTime
ist dazu gedacht, Benutzern angezeigt zu werden, aber kein Mensch lebt in der "UTC" Zeitzone. Wenn Sie die Zeitzone zum Zeitpunkt der Erstellung nicht kennen, aber die lokale Uhrzeit wissen, verwenden Sie einen Temporal.PlainDateTime
. Wenn Sie den genauen Moment kennen, verwenden Sie einen Temporal.Instant
.
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 dieselbe Form wie der Offset hat, außer dass Unterminuten-Präzision nicht erlaubt ist. Zum Beispiel sind +05:30
, -08
, +0600
alle gültige Offsets. Intern werden die Offset-Bezeichner in der ±HH:mm
-Form gespeichert.
Hinweis: Vermeiden Sie es, Offset-Bezeichner zu verwenden, wenn Sie stattdessen eine benannte Zeitzone verwenden können. Selbst wenn eine Region immer nur einen Offset verwendet hat, ist es besser, den benannten Identifier zu verwenden, um sich gegen zukünftige politische Änderungen des Offsets zu schützen.
Wenn eine Region mehrere Offsets verwendet (oder verwendet hat), dann ist die Verwendung ihrer benannten Zeitzone noch wichtiger. Dies liegt daran, dass Temporal.ZonedDateTime
Methoden wie add
oder with
verwenden kann, um neue Instanzen zu einem anderen Moment zu erstellen. Wenn diese abgeleiteten Instanzen einem Moment entsprechen, der einen anderen Offset verwendet (z.B. nach einer Sommerzeitumstellung), dann werden Ihre Berechnungen eine inkorrekte lokale Zeit haben. Die Verwendung einer benannten Zeitzone stellt sicher, dass lokale Daten und Zeiten immer für den korrekten Offset zu diesem Zeitpunkt angepasst werden.
Der Einfachheit halber, wenn Sie einen Zeitzonen-Identifier zu Temporal
-APIs wie Temporal.ZonedDateTime.prototype.withTimeZone()
und der timeZoneId
-Option von Temporal.ZonedDateTime.from()
bereitstellen, können Sie ihn in einigen anderen Formen angeben:
- Als eine andere
ZonedDateTime
-Instanz, derentimeZoneId
verwendet wird. - Als ein RFC 9557 String mit einer Zeitzonenannotation, deren Zeitzonen-Identifikator verwendet wird.
- Als ein ISO 8601 / RFC 3339 String, der einen Offset enthält, dessen Offset als Offset-Identifikator verwendet wird; oder, wenn
Z
verwendet wird, wird die"UTC"
-Zeitzone verwendet. Diese Verwendung wird im Allgemeinen nicht empfohlen, da, wie oben erläutert, Offset-Identifikatoren die Möglichkeit fehlt, andereTemporal.ZonedDateTime
Instanzen sicher über eine Offset-Übergang wie beim Start oder Ende der Sommerzeit abzuleiten. Betrachten Sie stattdessen nurTemporal.Instant
zu verwenden oder die tatsächliche benannte Zeitzone des Nutzers abzurufen.
Die IANA-Zeitzonendatenbank ändert sich von Zeit zu Zeit, normalerweise um neue Zeitzonen als Reaktion auf politische Änderungen hinzuzufügen. Allerdings werden IANA-Zeitzonen-Identifier selten umbenannt, um die aktualisierte englische Übersetzung eines Städtenamens wiederzugeben oder um veraltete Namenskonventionen zu aktualisieren. Zum Beispiel hier ein paar bemerkenswerte Namensänderungen:
Aktueller IANA primärer Identifier | Alter, jetzt nicht primärer Identifier |
---|---|
America/Argentina/Buenos_Aires |
America/Buenos_Aires |
Asia/Kolkata |
Asia/Calcutta |
Asia/Ho_Chi_Minh |
Asia/Saigon |
Europe/Kyiv |
Europe/Kiev |
Historisch verursachten diese Umbenennungen Probleme für Programmierer, weil die Unicode CLDR-Datenbank (eine von Browsern genutzte Bibliothek zur Bereitstellung von Zeitzonen-Identifikatoren und -Daten) IANAs Umbenennungen aus Stabilitätsgründen nicht ins Auge fasste. Infolgedessen berichteten einige Browser wie Chrome und Safari die veralteten Identifier von CLDR, während andere Browser wie Firefox die voreingestellten Werte von CLDR überschrieben und die aktuellen primären Identifier meldeten.
Mit der Einführung von Temporal ist dieses Verhalten nun mehr standardisiert:
- CLDR-Daten enthalten nun ein
"_iana"
Attribut, das den neuesten Bezeichner angibt, wenn der ältere, stabile Bezeichner umbenannt wurde. Browser können dieses neue Attribut verwenden, um den Aufrufern aktuelle Identifikationen bereitzustellen. - Zeitzonen-Identifikatoren, die vom Programmierer bereitgestellt werden, werden niemals durch einen Alias ersetzt. Zum Beispiel, wenn der Aufrufer
Asia/Calcutta
oderAsia/Kolkata
als Identifikator-Eingabe zuTemporal.ZonedDateTime.from()
bereitstellt, wird derselbe Identifier in der resultierenden Instanz'stimeZoneId
zurückgegeben. Beachten Sie, dass die Buchstabengröße der Ausgaben normalisiert wird, um IANA zu entsprechen. Daher erzeugtASIA/calCuTTa
als Eingabe einetimeZoneId
vonAsia/Calcutta
als Ausgabe. - Wenn ein Zeitzonen-Identifier nicht von einem Aufrufer bereitgestellt wird, sondern stattdessen vom System selbst bezogen wird (z.B. bei der Verwendung von
Temporal.Now.timeZoneId()
), werden moderne Identifier in allen Browsern zurückgegeben. Bei Städtenamenänderungen gibt es eine zweijährige Verzögerung, bevor diese systembereitgestellten Bezeichnungs-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 Attribuierung der primären Identifier länderspezifisch bleibt: Zum Beispiel verzeichnet die IANA-Datenbank Atlantic/Reykjavik
als Alias für Africa/Abidjan
, aber da sie unterschiedlichen Ländern (Island bzw. Côte d'Ivoire) entsprechen, werden sie als unterschiedliche primäre Identifier behandelt.
Diese Standardisierung gilt auch außerhalb von Temporal
. Zum Beispiel wird die timeZone
-Option, die von Intl.DateTimeFormat.prototype.resolvedOptions()
zurückgegeben wird, auch niemals durch einen Alias ersetzt, obwohl Browser diese Identifier traditionell vor der Standardisierung durch Temporal kanonisiert haben. Andererseits würden 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ückgaben.
RFC 9557 Format
ZonedDateTime
Objekte können mithilfe des RFC 9557 Formats serialisiert und analysiert werden, einer Erweiterung des ISO 8601 / RFC 3339 Formats. Der String hat die folgende Form (Leerzeichen sind nur zur Lesbarkeit und sollen im eigentlichen 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
bis12
. DD
-
Eine zweistellige Zahl von
01
bis31
. DieYYYY
,MM
undDD
Komponenten können durch-
oder gar nichts getrennt werden. T
Optional-
Der Datums-/Zeit-Trenner, der
T
,t
oder ein Leerzeichen sein kann. Vorhanden, falls und nur wennHH
vorhanden ist. HH
Optional-
Eine zweistellige Zahl von
00
bis23
. Standardmäßig00
. mm
Optional-
Eine zweistellige Zahl von
00
bis59
. Standardmäßig00
. ss.sssssssss
Optional-
Eine zweistellige Zahl von
00
bis59
. Kann optional mit einem.
oder,
und eins bis neun Ziffern gefolgt werden. Standardmäßig00
. DieHH
,mm
undss
Komponenten können durch:
oder nichts getrennt werden. Sie können entweder nurss
oder sowohlss
als auchmm
auslassen, so dass die Zeit in einer der drei Formen sein kann:HH
,HH:mm
, oderHH:mm:ss.sssssssss
. Z/±HH:mm
Optional-
Entweder der UTC-Indikator
Z
oderz
, oder ein Offset von UTC in der Form+
oder-
, gefolgt durch dasselbe Format wie die Zeitkomponente. Beachten Sie, dass Unterminuten-Präzision (:ss.sssssssss
) von anderen Systemen möglicherweise nicht unterstützt wird und akzeptiert, aber nie ausgegeben wird. Falls weggelassen, wird der Offset aus dem Zeitzonen-Identifier abgeleitet. Falls vorhanden, muss dann auch die Zeit bereitgestellt werden.Z
ist nicht dasselbe wie+00:00
: Letzteres bedeutet, dass die Zeit in lokaler Zeit angegeben ist, die zufällig UTC+0 ist, und wird gegen den Zeitzonen-Identifier via deroffset
option validiert. [time_zone_id]
-
Ersetzen Sie
time_zone_id
durch den Zeitzonen-Identifikator (benannt oder Offset) wie oben beschrieben. Kann ein kritisches Flag haben, indem der Identifier 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 es fürTemporal.ZonedDateTime.from()
erforderlich ist: Falls weggelassen, wird einRangeError
ausgelöst. Wenn Sie ISO 8601 / RFC 3339 Strings ohne Zeitzonen-Identifier-Annotations analysieren möchten, verwenden SieTemporal.Instant.from()
stattdessen. [u-ca=calendar_id]
Optional-
Ersetzen Sie
calendar_id
durch das zu verwendende Kalendersystem. 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. DerTemporal
-Parser wird einen Fehler auslösen, wenn die Anmerkungen zwei oder mehr Kalenderanmerkungen enthalten und eine davon kritisch ist. Standardmäßig[u-ca=iso8601]
. Beachten Sie, dass dasYYYY-MM-DD
stets als ISO 8601 Kalenderdatum interpretiert und dann in das angegebene Kalender konvertiert wird.
Als Eingabe werden andere Anmerkungen im [key=value]
Format ignoriert und dürfen kein kritisches Flag haben.
Bei der Serialisierung können Sie die Bruchteile der Sekunde, ob der Offset/Zeitzonen-ID/Kalender-ID angezeigt werden soll, und ob für die Anmerkungen ein kritisches Flag hinzugefügt werden soll, konfigurieren.
Mehrdeutigkeit und Lücken von lokaler Zeit zu UTC-Zeit
Angesichts einer Zeitzone ist die Umstellung von UTC auf lokale Zeit einfach: Zuerst erhält man den Offset mit dem Zeitzonennamen und dem Moment, dann fügt man den Offset zum Moment hinzu. Das Gegenteil ist nicht wahr: Die Umstellung von lokaler Zeit auf UTC ist ohne einen expliziten Offset mehrdeutig, da eine lokale Zeit zu null, einem oder vielen UTC-Zeiten gehören kann. Betrachten Sie die häufigste Ursache: Sommerzeitumstellungen. Nehmen Sie zum Beispiel New York. Sein Standardoffset ist UTC-5, aber während der Sommerzeit werden alle Uhren um eine Stunde vorgestellt, sodass der Offset UTC-4 wird. In den USA erfolgen Übergänge um 2:00 Uhr Ortszeit, also betrachten Sie diese beiden Übergangstage:
UTC-Zeit | New Yorker Zeit |
---|---|
2024-03-10T06:58:00Z | 2024-03-10T01:58:00-05:00 |
2024-03-10T06:59:00Z | 2024-03-10T01:59:00-05:00 |
2024-03-10T07:00:00Z | 2024-03-10T03:00:00-04:00 |
--- | --- |
2024-11-03T05:58:00Z | 2024-11-03T01:58:00-04:00 |
2024-11-03T05:59:00Z | 2024-11-03T01:59:00-04:00 |
2024-11-03T06:00:00Z | 2024-11-03T01:00:00-05:00 |
Wie Sie sehen können, verschwand im März eine Stunde aus der lokalen Zeit, und im November gibt es zwei Stunden, die die gleiche Uhrzeit haben. Angenommen, wir haben ein PlainDateTime
gespeichert, das "2024-03-10T02:05:00" sagt, und wir wollen es in der America/New_York
-Zeitzone interpretieren, dann wird es keine Zeit geben, die ihm entspricht, während ein PlainDateTime
, das "2024-11-03T01:05:00" sagt, zu zwei verschiedenen Momenten gehören kann.
Wenn ein ZonedDateTime
aus einer lokalen Uhrzeit konstruiert wird (unter Verwendung 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. Falls es eine Lücke gibt, gehen Sie um die Lückendauer zurück.
later
-
Wenn es zwei mögliche Momente gibt, wählen Sie den späteren. Falls es eine Lücke gibt, gehen Sie um die Lückendauer vor.
compatible
(Standard)-
Gleiches Verhalten wie
Date
: Verwenden Sielater
für Lücken undearlier
für Mehrdeutigkeiten. reject
-
Werfen Sie einen
RangeError
, wann immer eine Mehrdeutigkeit oder eine Lücke auftritt.
Es gibt mehrere Fälle, in denen es keine Mehrdeutigkeit beim Konstruieren eines ZonedDateTime
gibt:
- Falls die Zeit explizit in UTC über den
Z
-Offset angegeben wird. - Wenn der Offset explizit bereitgestellt und verwendet wird (siehe unten).
Offset-Mehrdeutigkeit
Wir haben bereits gezeigt, wie Mehrdeutigkeit entstehen kann, wenn eine lokale Zeit in einer Zeitzone interpretiert wird, ohne einen expliziten Offset bereitzustellen. Wenn Sie jedoch einen expliziten Offset angeben, entsteht ein weiterer Konflikt: zwischen dem Offset wie angegeben und dem Offset, wie er aus der Zeitzone und der lokalen Zeit berechnet wird. Dies ist ein unvermeidbares realweltliches Problem: Wenn Sie eine Zeit in der Zukunft speichern, mit einem erwarteten Offset, bevor diese Zeit kommt, könnte sich die Zeitzonendefinition aus politischen Gründen geändert haben. Beispielsweise, angenommen, wir setzen 2018 eine Erinnerung auf die Zeit 2019-12-23T12:00:00-02:00[America/Sao_Paulo]
(das sich in der Sommerzeit befindet; Brasilien ist auf der Südhalbkugel, so dass es im Oktober in die Sommerzeit eintritt und im Februar austritt). Aber bevor diese Zeit kommt, entscheidet Brasilien Anfang 2019, die Sommerzeit nicht mehr zu beachten, so dass der reale Offset -03:00
wird. Sollte die Erinnerung jetzt immer noch um Mittag ausgelöst werden (die lokale Zeit haltend), oder sollte sie um 11:00 Uhr ausgelöst werden (die genaue Zeit haltend)?
Beim Konstruieren eines ZonedDateTime
mit Temporal.ZonedDateTime.from()
oder beim Aktualisieren mit der with()
Methode ist das Verhalten für Offset-Mehrdeutigkeit über die offset
-Option konfigurierbar:
use
-
Verwenden Sie den Offset, um die genaue Zeit zu berechnen. Diese Option "verwendet" den Offset, um den durch den String dargestellten Moment zu bestimmen, der derselbe Moment sein wird, der ursprünglich berechnet wurde, als wir die Zeit speicherten, selbst wenn sich der Offset zu dem Moment geändert hat. Der Zeitzonen-Identifier wird weiterhin verwendet, um den (möglicherweise aktualisierten) Offset abzuleiten und verwendet diesen Offset, um die genaue Zeit in die lokale Zeit zu konvertieren.
ignore
-
Verwenden Sie den Zeitzonen-Identifier, um den Offset neu zu berechnen, und ignorieren Sie den im String angegebenen Offset. Diese Option behält die gleiche lokale Zeit, die ursprünglich berechnet wird, wenn wir die Zeit gespeichert haben, kann jedoch einem anderen Moment entsprechen. Beachten Sie, dass diese Option die gleiche lokale Zeit-Interpretationsmehrdeutigkeit verursachen kann, wie bereits oben demonstriert, die mit der
disambiguation
-Option gelöst wird. reject
-
Werfen Sie einen
RangeError
, wann immer es zu einem Konflikt zwischen dem Offset und dem Zeitzonen-Identifier kommt. Dies ist der Standard fürTemporal.ZonedDateTime.from()
. prefer
-
Verwenden Sie den Offset, wenn er gültig ist, andernfalls berechnen Sie den Offset aus dem Zeitzonen-Identifier. Dies ist der Standard für
Temporal.ZonedDateTime.prototype.with()
(siehe die Methode für mehr Details). Dies ist anders alsignore
, weil bei lokaler Zeit-Mehrdeutigkeit der Offset verwendet wird, um sie zu lösen, anstatt derdisambiguation
-Option.
Beachten Sie, dass der Z
Offset nicht +00:00
bedeutet; er wird immer als gültig angesehen, unabhängig von der Zeitzone. 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 das gleiche Verhalten wie die ignore
-Option und seine Ergebnisse können nie mehrdeutig sein.
Hinweis:
Obwohl Temporal.Instant.from()
auch einen RFC 9557 String in derselben Form annimmt, gibt es keine Mehrdeutigkeit, da es immer den Zeitzonen-Identifier ignoriert und nur den Offset liest.
Konstruktor
Temporal.ZonedDateTime()
Experimentell-
Erstellt ein neues
Temporal.ZonedDateTime
Objekt durch direktes Übergeben der zugrundeliegenden Daten.
Statische Methoden
Temporal.ZonedDateTime.compare()
Experimentell-
Gibt eine Zahl (-1, 0 oder 1) zurück, die angibt, ob die erste Datum-Zeit vor, genau gleich oder nach der zweiten Datum-Zeit kommt. Entspricht dem Vergleich der
epochNanoseconds
der beiden Datums- und Zeitangaben. Temporal.ZonedDateTime.from()
Experimentell-
Erstellt ein neues
Temporal.ZonedDateTime
Objekt aus einem anderenTemporal.ZonedDateTime
Objekt, einem Objekt mit Datums-, Zeit- und Zeitzonen-Eigenschaften 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 darstellt, 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 derTemporal.ZonedDateTime()
Konstruktor. Temporal.ZonedDateTime.prototype.day
Experimentell-
Gibt eine positive Ganzzahl zurück, die den 1-basierten Tagindex im Monat dieses Datums darstellt, der dieselbe Tagesnummer ist, die Sie auf einem Kalender sehen würden. Abhängig vom Kalender. Allgemein beginnt bei 1 und ist kontinuierlich, aber nicht immer.
Temporal.ZonedDateTime.prototype.dayOfWeek
Experimentell-
Gibt eine positive Ganzzahl zurück, die den 1-basierten Tagindex der Woche dieses Datums darstellt. Tage in einer Woche sind sequentiell von
1
bisdaysInWeek
nummeriert, wobei jede Zahl ihrem Namen zugeordnet ist. Abhängig vom Kalender. 1 repräsentiert gewöhnlich Montag im Kalender, selbst wenn Lokalisierungen, die den Kalender verwenden, einen anderen Tag als ersten Tag der Woche betrachten (sieheIntl.Locale.prototype.getWeekInfo()
). Temporal.ZonedDateTime.prototype.dayOfYear
Experimentell-
Gibt eine positive Ganzzahl zurück, die den 1-basierten Tagindex im Jahr dieses Datums darstellt. Der erste Tag dieses Jahres ist
1
, und der letzte Tag ist derdaysInYear
. Abhängig vom Kalender. Temporal.ZonedDateTime.prototype.daysInMonth
Experimentell-
Gibt eine positive Ganzzahl zurück, die die Anzahl der Tage im Monat dieses Datums darstellt. Abhängig vom Kalender.
Temporal.ZonedDateTime.prototype.daysInWeek
Experimentell-
Gibt eine positive Ganzzahl zurück, die die Anzahl der Tage in der Woche dieses Datums darstellt. Abhängig vom Kalender. 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. Abhängig vom Kalender. 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 darstellt, die seit der Unix-Epoche (Mitternacht am Beginn des 1. Januar 1970, UTC) bis zu diesem Moment vergangen sind. Entspricht der Division von
epochNanoseconds
durch1e6
und der Abrundung des Ergebnisses. Temporal.ZonedDateTime.prototype.epochNanoseconds
Experimentell-
Gibt ein
BigInt
zurück, das die Anzahl der Nanosekunden darstellt, die seit der Unix-Epoche (Mitternacht am 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 Ära dieses Datums darstellt, oder
undefined
, wenn der Kalender keine Äras verwendet (z.B. ISO 8601).era
underaYear
zusammen identifizieren ein Jahr in einem Kalender eindeutig, auf die gleiche Weise, wie esyear
tut. Abhängig vom Kalender. Für Gregorianisch ist es entweder"gregory"
oder"gregory-inverse"
. Temporal.ZonedDateTime.prototype.eraYear
Experimentell-
Gibt eine nicht-negative Ganzzahl zurück, die das Jahr dieses Datums innerhalb der Ära darstellt, oder
undefined
, wenn der Kalender keine Äras verwendet (z.B. ISO 8601). Der Jahrindex beginnt normalerweise bei 1 (häufiger) oder 0, und Jahre in einer Ära können mit der Zeit abnehmen (z.B. Gregorianisch BCE).era
underaYear
zusammen identifizieren ein Jahr in einem Kalender eindeutig, auf dieselbe Weise, wieyear
es tut. Abhängig vom Kalender.