Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Temporal/ZonedDateTime below:

Temporal.ZonedDateTime - JavaScript | MDN

Limited availability

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 stellt ein Datum und eine Uhrzeit mit einer Zeitzone dar. Es wird grundsätzlich als Kombination aus einem Instant, einer Zeitzone und einem Kalendersystem repräsentiert.

Ein ZonedDateTime fungiert als Brücke zwischen einer exakten Zeit und einer "Wall Clock"-Zeit: Es repräsentiert gleichzeitig einen Moment in der Geschichte (wie ein Temporal.Instant) und eine lokale "Wall Clock"-Zeit (wie ein Temporal.PlainDateTime). Dies wird erreicht, indem der Moment, die Zeitzone und das Kalendersystem gespeichert werden. Die Zeitzone wird verwendet, um zwischen dem Moment und der lokalen Zeit zu konvertieren, und das Kalendersystem dient dazu, die lokale Zeit zu interpretieren.

ZonedDateTime ist die einzige Temporal-Klasse, die einer Zeitzone-bewusst ist. Durch die Hinzufügung einer Zeitzone unterscheiden sich ZonedDateTime Objekte in ihrem Verhalten deutlich von Temporal.PlainDateTime Objekten. Vor allem kann nicht mehr davon ausgegangen werden, 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- und Ortszeit beeinflussen.

Alle Zeiten in JavaScript haben einen goldenen Standard: die UTC-Zeit, die kontinuierlich und gleichmäßig inkrementiert wird, sobald physische Zeit fortschreitet. 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- und Ortszeit 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" beträgt, dann ist die lokale Zeit:

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

Indem diese Ortszeit mit dem Offset versehen wird, und somit diese Zeit als "1969-12-31T19:00:00-05:00" ausgedrückt wird, kann sie jetzt 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 ein Gebiet auf der Erde, in dem dasselbe Offset zu allen Zeiten verwendet wird. Zwei Uhren in derselben Zeitzone zeigen immer gleichzeitig dieselbe Zeit an, aber das Offset ist nicht unbedingt konstant: das heißt, die Zeiten dieser Uhren können sich abrupt ändern. Dies geschieht häufig während der Umstellungen der Sommerzeit, bei denen das Offset um eine Stunde geändert wird, was zweimal im Jahr passiert. Offsets können sich auch dauerhaft ändern aufgrund politischer Änderungen, z.B. wenn ein Land die Zeitzonen wechselt.

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

• Eine primäre Zeitzonenkennung, die die Zeitzone eindeutig identifiziert. Sie bezieht sich in der Regel auf ein geografisches Gebiet, das von einer Stadt verankert ist (z.B. Europe/Paris oder Africa/Kampala), kann aber auch einzeln-offset-Zeitzonen wie UTC (ein konstantes +00:00 Offset) oder Etc/GMT+5 (aus historischen Gründen ein negatives Offset -05:00) bezeichnen. Aus historischen Gründen ist der primäre Name für die UTC-Zeitzone UTC, obwohl es in IANA Etc/UTC ist.
• Eine Zeitzonendefinition in Form einer Tabelle, die UTC-Datum/Uhrzeit-Bereiche (einschließlich zukünftiger Bereiche) mit spezifischen Offsets verknüpft.
• Null oder mehr nicht-primäre Zeitzonenkennungen, die Aliase zur primären Zeitzonenkennung sind. Dies sind in der Regel historische Namen, die nicht mehr in Gebrauch sind, aber aus Kompatibilitätsgründen beibehalten werden. Siehe unten für weitere Informationen.

Als Eingabe werden benannte Kennungen ohne Beachtung der Groß-/Kleinschreibung abgeglichen. Intern werden sie in ihrer bevorzugten Schreibweise gespeichert, und nicht-primäre Kennungen werden nicht in ihre primäre Kennung konvertiert.

Hinweis: Wenn Sie den Zeitzonennamen einstellen, möchten Sie ihn selten auf "UTC" setzen. ZonedDateTime soll für Benutzer angezeigt werden, aber kein Mensch lebt in der "UTC"-Zeitzone. Wenn Sie die Zeitzone zum Zeitpunkt der Konstruktion nicht kennen, aber die "Wall Clock"-Zeit kennen, verwenden Sie einen Temporal.PlainDateTime. Wenn Sie den genauen Moment kennen, verwenden Sie einen Temporal.Instant.

Wenn eine Temporal-API eine Zeitzonenkennung akzeptiert, akzeptiert sie zusätzlich zu primären Zeitzonenkennungen und nicht-primären Zeitzonenkennungen auch eine Offset-Zeitzonenkennung, die in derselben Form wie das Offset vorliegt, jedoch ist Subminuten-Genauigkeit nicht erlaubt. Zum Beispiel, +05:30, -08, +0600 sind alle gültige Offset-Kennungen. Intern werden Offset-Kennungen im ±HH:mm-Format gespeichert.

Hinweis: Vermeiden Sie die Verwendung von Offset-Kennungen, wenn es eine benannte Zeitzone gibt, die Sie stattdessen verwenden können. Auch wenn eine Region immer ein einzelnes Offset verwendet hat, ist es besser, die benannte Kennung zu verwenden, um zukünftige politische Änderungen des Offsets abzusichern.

Wenn eine Region mehrere Offsets verwendet (oder verwendet hat), ist die Verwendung ihrer benannten Zeitzone sogar noch wichtiger. Dies liegt daran, dass Temporal.ZonedDateTime Methoden wie add oder with verwenden kann, um neue Instanzen zu einem anderen Zeitpunkt zu erstellen. Wenn diese abgeleiteten Instanzen einem Moment entsprechen, der ein anderes Offset verwendet (zum Beispiel nach einer Umstellung der Sommerzeit), dann werden Ihre Berechnungen eine falsche lokale Zeit aufweisen. Die Verwendung einer benannten Zeitzone stellt sicher, dass lokale Daten und Zeiten immer für das richtige Offset für diesen Moment angepasst werden.

Zur Bequemlichkeit, wenn Sie einer Temporal-API wie Temporal.ZonedDateTime.prototype.withTimeZone() und der timeZoneId-Option von Temporal.ZonedDateTime.from() eine Zeitzonenkennung bereitstellen, können Sie diese in einigen anderen Formen bereitstellen:

• Als eine andere ZonedDateTime-Instanz, deren timeZoneId verwendet wird.
• Als eine RFC 9557-Zeichenfolge mit einer Zeitzonenanmerkung, deren Zeitzonenkennung verwendet wird.
• Als eine ISO 8601 / RFC 3339-Zeichenfolge, die ein Offset enthält, dessen Offset als Offset-Kennung verwendet wird; oder, wenn Z verwendet wird, dann wird die "UTC"-Zeitzone verwendet. Diese Nutzung wird im Allgemeinen nicht empfohlen, weil, wie oben erwähnt, Offset-Kennungen die Fähigkeit fehlt, sicher andere Temporal.ZonedDateTime-Instanzen über eine Offset-Übergänge zu erzeugen, wie sie beim Beginn oder Ende der Sommerzeit auftreten. Stattdessen sollten Sie Temporal.Instant verwenden oder die tatsächliche benannte Zeitzone des Benutzers abrufen.

Die IANA-Zeitzonendatenbank ändert sich von Zeit zu Zeit, in der Regel um neue Zeitzonen im Zuge politischer Veränderungen hinzuzufügen. Gelegentlich werden jedoch IANA-Zeitzonenkennungen umbenannt, um eine aktualisierte englische Übersetzung eines Stadtnamens widerzuspiegeln oder um veraltete Namenskonventionen zu aktualisieren. Zum Beispiel sind hier einige bemerkenswerte Namensänderungen:

Historisch gesehen, haben diese Umbenennungen Probleme für Programmierer verursacht, weil die Unicode-CLDR-Datenbank (eine Bibliothek, auf die Browser angewiesen sind, um Zeitzonenkennungen und -daten bereitzustellen) IANAs Umbenennung aus Stabilitätsgründen nicht folgte. Infolgedessen berichteten einige Browser wie Chrome und Safari die veralteten CLDR-Bezeichner, während andere Browser wie Firefox die Standardwerte von CLDR überschrieben und die aktuellen primären Bezeichner berichteten.

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

• Die CLDR-Daten enthalten jetzt ein "_iana"-Attribut, das den aktuellsten Bezeichner angibt, wenn der ältere stabile Bezeichner umbenannt wurde. Browser können dieses neue Attribut verwenden, um Anrufern aktuelle Bezeichner bereitzustellen.
• Zeitzonenkennungen, die vom Programmierer bereitgestellt werden, werden niemals durch einen Alias ersetzt. Zum Beispiel, wenn der Anrufer Asia/Calcutta oder Asia/Kolkata als Bezeichnereingabe für Temporal.ZonedDateTime.from() bereitstellt, wird derselbe Bezeichner in der resultierenden Instanz von timeZoneId zurückgegeben. Beachten Sie, dass die Groß- und Kleinschreibung der Ausgaben an IANA angepasst wird, so dass ASIA/calCuTTa als Eingabe eine timeZoneId von Asia/Calcutta als Ausgabe erzeugt.
• Wenn eine Zeitzonenkennung nicht vom Anrufer bereitgestellt wird, sondern stattdessen aus dem System selbst stammt (zum Beispiel bei Verwendung von Temporal.Now.timeZoneId()), werden in allen Browsern moderne Bezeichner zurückgegeben. Bei Stadtnamenänderungen gibt es eine Übergangszeit von zwei Jahren, bevor diese systembasierten Bezeichner-APIs den neuen Namen freilegen, was anderen Komponenten (wie einem Node-Server) Zeit gibt, ihre Kopien der IANA-Datenbank zu aktualisieren, um den neuen Namen zu erkennen.

Beachten Sie, dass die Zuschreibung primärer Bezeichner den Ländercode beibehält: zum Beispiel zeichnet die IANA-Datenbank Atlantic/Reykjavik als Alias für Africa/Abidjan auf, aber weil sie verschiedenen Ländern entsprechen (Island bzw. Côte d'Ivoire), werden sie als unterschiedliche primäre Bezeichner 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 traditionell diese Bezeichner vor der Standardisierung durch Temporal kanonisiert haben. Auf der anderen Seite, Intl.Locale.prototype.getTimeZones() und Intl.supportedValuesOf() (timeZone Option) werden den aktuellsten Bezeichner zurückgeben, während einige Browser früher den alten, nicht-primären Bezeichner 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 das folgende Format (Leerzeichen dienen nur der Lesbarkeit und sollten 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 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-Zeit-Trenner, 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. 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 ein . oder , gefolgt von einer bis neun Ziffern ergänzt werde. Standardmäßig 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 Uhrzeit in einer von drei Formen vorliegen kann: HH, HH:mm oder HH:mm:ss.sssssssss.

Z/±HH:mm Optional

Entweder der UTC-Kennzeichner Z oder z, oder ein Offset von UTC in der Form + oder - gefolgt von demselben Format wie die Zeitkomponente. Beachten Sie, dass Subminuten-genauigkeit (:ss.sssssssss) von anderen Systemen möglicherweise nicht unterstützt wird und akzeptiert, aber nie ausgegeben wird. Wenn weggelassen, wird das Offset aus der Zeitzonenkennung abgeleitet. Wenn vorhanden, 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 von der Zeitzonenkennung, während letzteres bedeutet, dass die Zeit in Ortszeit angegeben wird, die zufällig UTC+0 ist, und gegen die Zeitzonenkennung über die offset-Option validiert wird.

[time_zone_id]

Ersetzen Sie time_zone_id durch die Zeitzonenkennung (benannt oder offset) wie oben beschrieben. Kann ein kritisches Flag haben, indem der Bezeichner mit ! versehen wird: zum Beispiel [!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ür Temporal.ZonedDateTime.from() erforderlich ist: das Weglassen verursacht einen RangeError. Wenn Sie ISO 8601 / RFC 3339-Zeichenfolgen ohne Zeitzonenkennung-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 häufig unterstützten Kalenderarten. Standardmäßig [u-ca=iso8601]. Kann ein kritisches Flag durch Präfixierung des Schlüssels mit ! haben: zum Beispiel [!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 Anmerkungen zwei oder mehr Kalenderanmerkungen 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 Eingabe werden andere Anmerkungen im [key=value]-Format ignoriert, und sie dürfen nicht das kritische Flag haben.

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

Angenommen eine Zeitzone, ist die Umwandlung von UTC in Ortszeit einfach: Sie erhalten zuerst das Offset, indem Sie den Zeitzonennamen und den Moment verwenden, dann addieren Sie das Offset zum Moment. Das Umgekehrte ist nicht wahr: Die Umwandlung von Ortszeit in UTC-Zeit ohne ein explizites Offset ist mehrdeutig, da eine Ortszeit null, einem oder mehreren UTC-Zeiten entsprechen kann. Betrachten Sie die häufigste Ursache: Umstellungen der Sommerzeit. Nehmen Sie New York zum Beispiel. Sein Standardoffset ist UTC-5, aber während der Sommerzeit werden alle Uhren um eine Stunde vorgestellt, sodass das Offset UTC-4 wird. In den USA erfolgen die Umstellungen um 2:00 Uhr Ortszeit, betrachten Sie daher diese zwei Ü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 Wandzeitzone besitzen. Angenommen, wir haben ein PlainDateTime gespeichert, das "2024-03-10T02:05:00" sagt, und wir möchten es in der America/New_York-Zeitzone interpretieren, es wird keine Zeit geben, die dazu gehört, während ein PlainDateTime, das "2024-11-03T01:05:00" sagt, zwei verschiedenen Momenten entsprechen kann.

Beim Erstellen eines ZonedDateTime aus einer Ortszeit (unter Verwendung von 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 durch 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 durch 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 beim Erstellen eines ZonedDateTime gibt:

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

Wir haben bereits demonstriert, wie Mehrdeutigkeit durch die Interpretation einer Ortszeit in einer Zeitzone ohne Angabe eines expliziten Offsets entstehen kann. Wenn Sie jedoch ein explizites Offset angeben, entsteht ein anderer Konflikt: zwischen dem angegebenen Offset und dem aus der Zeitzone und der Ortszeit berechneten Offset. Dies ist ein unvermeidliches Problem in der realen Welt: Wenn Sie eine Zeit in der Zukunft mit einem erwarteten Offset speichern, kann vor dieser Zeit die Zeitzonendefinition aufgrund politischer Gründe geändert werden. Zum Beispiel, nehmen wir an, im Jahr 2018 setzen wir eine Erinnerung auf 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 und tritt im Oktober ein und im Februar aus der Sommerzeit). Aber vor dieser Zeit, Anfang 2019, entscheidet Brasilien, die Sommerzeit nicht mehr zu beachten, sodass das tatsächliche Offset -03:00 wird. Soll die Erinnerung nun immer noch um Mittag ausgelöst werden (was die Ortszeit beibehält), oder soll sie um 11:00 Uhr ausgelöst werden (was die exakte Zeit beibehält)?

Bei der Erstellung eines ZonedDateTime mit Temporal.ZonedDateTime.from() oder bei der Aktualisierung mit der with()-Methode, ist das Verhalten bei Offset-Mehrdeutigkeit über die offset-Option konfigurierbar:

use

Verwenden Sie das Offset, um die exakte Zeit zu berechnen. Diese Option "verwendet" das Offset, um den Moment zu bestimmen, der durch den String repräsentiert wird, welcher derselbe Moment sein wird, wie er ursprünglich berechnet wurde, als wir die Zeit gespeichert haben, selbst wenn das Offset zu diesem Moment sich geändert hat. Die Zeitzonenkennung wird dennoch verwendet, um dann das (möglicherweise aktualisierte) Offset abzuleiten und dieses Offset zu verwenden, um die exakte Zeit in die Ortszeit zu konvertieren.

ignore

Verwenden Sie die Zeitzonenkennung, um das Offset neu zu berechnen, und ignorieren Sie das im String angegebene Offset. Diese Option behält die ursprüngliche Ortszeit bei, die beim Speichern der Zeit berechnet wurde, kann jedoch einem anderen Moment entsprechen. Beachten Sie, dass diese Option die gleiche Ortszeit-Interpretationsmehrdeutigkeit verursachen kann, wie oben gezeigt, die mit der disambiguation-Option gelöst wird.

reject

Werfen Sie einen RangeError, wann immer es einen Konflikt zwischen dem Offset und der Zeitzonenkennung gibt. Dies ist die Standardeinstellung für Temporal.ZonedDateTime.from().

prefer

Verwenden Sie das Offset, wenn es gültig ist, andernfalls berechnen Sie das Offset aus der Zeitzonenkennung. Dies ist die Standardeinstellung für Temporal.ZonedDateTime.prototype.with() (siehe die Methode für mehr Details). Dies unterscheidet sich von ignore, weil im Fall von lokalem Zeitmehrdeutigkeiten das Offset zur Lösung verwendet wird, anstatt der disambiguation-Option.

Beachten Sie, dass das Z-Offset nicht gleichbedeutend mit +00:00 ist. Das Z-Offset bedeutet "die Zeit in UTC ist bekannt, aber das 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 Zeitzonenkennung abgeleitet. Andererseits wird das +00:00-Offset als ein lokales Zeit-Offset interpretiert, das zufällig UTC entspricht und gegen die Zeitzonenkennung validiert wird.

Hinweis: Obwohl Temporal.Instant.from() auch einen RFC 9557 String in derselben Form annimmt, gibt es keine Mehrdeutigkeit, weil sie immer die Zeitzonenkennung ignoriert und nur das Offset liest.

Temporal.ZonedDateTime() Experimentell

Erstellt ein neues Temporal.ZonedDateTime Objekt, indem direkt die zugrundeliegenden Daten bereitgestellt werden.

Temporal.ZonedDateTime.compare() Experimentell

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

Temporal.ZonedDateTime.from() Experimentell

Erstellt ein neues Temporal.ZonedDateTime Objekt aus einem anderen Temporal.ZonedDateTime Objekt, einem Objekt mit Datum-, Uhrzeit- 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 verwendeten Kalender zur Interpretation des internen ISO 8601 Datums repräsentiert.

Temporal.ZonedDateTime.prototype.constructor

Die Konstruktorfunktion, die das Instanzobjekt erstellt hat. Für Temporal.ZonedDateTime Instanzen ist der Anfangswert der Temporal.ZonedDateTime() Konstruktor.

Temporal.ZonedDateTime.prototype.day Experimentell

Gibt eine positive Ganzzahl zurück, die den 1-basierten Tag-Index im Monat dieses Datums darstellt, dasselbe Tag, das man in einem Kalender sehen würde. Kalender-abhängig, beginnt normalerweise bei 1 und ist fortlaufend, aber nicht immer.

Temporal.ZonedDateTime.prototype.dayOfWeek Experimentell

Gibt eine positive Ganzzahl zurück, die den 1-basierten Tag-Index 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 steht normalerweise für Montag im Kalender, obwohl bei Kalendern, die verwendet werden, ein anderer Tag als der erste Tag der Woche betrachtet wird (siehe Intl.Locale.prototype.getWeekInfo()).

Temporal.ZonedDateTime.prototype.dayOfYear Experimentell

Gibt eine positive Ganzzahl 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 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 ist dies immer 7, aber in anderen Kalendersystemen kann es von Woche zu Woche variieren.

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 ist dies 365, oder 366 in einem Schaltjahr.

Temporal.ZonedDateTime.prototype.epochMilliseconds Experimentell

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

Temporal.ZonedDateTime.prototype.epochNanoseconds Experimentell

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

Temporal.ZonedDateTime.prototype.era Experimentell

Gibt einen kalender-spezifischen, kleingeschriebenen 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, genauso wie year es tut. Kalender-abhängig. Für den gregorianischen Kalender ist es entweder "gregory" oder "gregory-inverse".

Temporal.ZonedDateTime.prototype.eraYear Experimentell

Gibt eine nicht-negative Ganzzahl zurück, die das Jahr innerhalb der Ära dieses Datums darstellt, oder undefined, wenn der Kalender keine Ären verwendet (z.B. ISO 8601). Der Jahresindex beginnt normalerweise bei 1 (häufiger) oder 0, und Jahre in einer Ära können mit der Zeit abnehmen (z.B. Gregorianischer Kalender vor Christus). era und eraYear zusammen identifizieren 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 kann mehr oder weniger als 24 sein im Falle von Offset-Änderungen wie der Sommerzeit.

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 Schalttags oder 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) Komponente dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.millisecond Experimentell

Gibt eine Ganzzahl von 0 bis 999 zurück, die die Millisekunde (10^-3 Sekunde) Komponente 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 die 1-basierte Monatsindexzahl im Jahr dieses Datums darstellt. Der erste Monat dieses Jahres ist 1, und der letzte Monat ist monthsInYear. Kalender-abhängig. Beachten Sie, dass, anders als Date.prototype.getMonth(), der Index 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 kalender-spezifischen String zurück, der den Monat dieses Datums darstellt. Kalender-abhängig. Normalerweise ist es M plus einer zweistelligen Monatszahl. Bei Schaltmonaten ist es der Code des vorhergehenden Monats, 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 ist das 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) Komponente dieser Zeit darstellt.

Temporal.ZonedDateTime.prototype.offset Experimentell

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

Temporal.ZonedDateTime.prototype.offsetNanoseconds Experimentell

Gibt eine Ganzzahl zurück, die das Offset darstellt, das zum Interpretieren des internen Moments verwendet wird, als Anzahl von 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 Zeitzonenbezeichner darstellt, der zum Interpretieren des internen Moments verwendet wird. Er nutzt denselben String, der beim Erstellen des Temporal.ZonedDateTime-Objekts verwendet wurde, der entweder ein IANA-Zeitzonenname oder ein festes Offset ist.

Temporal.ZonedDateTime.prototype.weekOfYear Experimentell

Gibt eine positive Ganzzahl zurück, die die 1-basierte Wochenindexzahl 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 im ISO 8601 Kalender 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 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 neuesten Ära oder das ISO 8601-Jahr 0001. Wenn die Epoche in der Mitte des Jahres liegt, wird dieses Jahr denselben Wert vor und nach dem Startdatum der Ära haben.

Temporal.ZonedDateTime.prototype.yearOfWeek Experimentell

Gibt eine Ganzzahl zurück, die das Jahr darstellt, das mit dem weekOfYear dieses Datums gepaart 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 zugeordnet werden, wodurch yearOfWeek sich 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 diese Datum-Zeit um eine gegebene Dauer (in einem Formular, das durch Temporal.Duration.from() konvertierbar ist) nach vorne bewegt.

Temporal.ZonedDateTime.prototype.equals() Experimentell

Gibt true zurück, wenn diese Datum-Zeit in ihrem Wert zu einer anderen Datum-Zeit (in einem Formular, das durch Temporal.ZonedDateTime.from() konvertierbar ist) gleichwertig ist, und false andernfalls. Sie werden sowohl durch ihre Momentwerte, Zeitzonen als auch durch ihre Kalender verglichen, sodass zwei Datum-Zeiten aus verschiedenen Kalendern oder Zeitzonen von Temporal.ZonedDateTime.compare() als gleich betrachtet werden können, nicht aber von equals().

Temporal.ZonedDateTime.prototype.getTimeZoneTransition() Experimentell

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

Temporal.ZonedDateTime.prototype.round() Experimentell

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

Temporal.ZonedDateTime.prototype.since() Experimentell

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

Temporal.ZonedDateTime.prototype.startOfDay() Experimentell

Gibt ein Temporal.ZonedDateTime-Objekt zurück, welches den ersten Moment dieses Tages in der Zeitzone darstellt. Normalerweise hat es eine Uhrzeit von 00:00:00, kann aber abweichen, wenn der Mitternachtspunkt aufgrund von Offset-Änderungen nicht existiert, in welchem Fall die erste existierende Uhrzeit zurückgegeben wird.

Temporal.ZonedDateTime.prototype.subtract() Experimentell

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diese Datum-Zeit um eine gegebene Dauer (in einem Formular, das von Temporal.Duration.from() konvertierbar ist) rückwärts bewegt.

Temporal.ZonedDateTime.prototype.toInstant() Experimentell

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

Temporal.ZonedDateTime.prototype.toJSON() Experimentell

Gibt einen String zurück, der diese Datum-Zeit im gleichen 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-Zeit zurück.

Temporal.ZonedDateTime.prototype.toPlainDate() Experimentell

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

Temporal.ZonedDateTime.prototype.toPlainDateTime() Experimentell

Gibt ein neues Temporal.PlainDateTime-Objekt zurück, das den Datums- und Zeitanteil dieser Datum-Zeit darstellt. Nur die Zeitzoneninformation wird entfernt.

Temporal.ZonedDateTime.prototype.toPlainTime() Experimentell

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

Temporal.ZonedDateTime.prototype.toString() Experimentell

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

Temporal.ZonedDateTime.prototype.until() Experimentell

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

Temporal.ZonedDateTime.prototype.valueOf() Experimentell

Wirft einen TypeError, der verhindert, dass Temporal.ZonedDateTime-Instanzen implizit in primitive Datentypen konvertiert 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-Zeit mit einigen durch neue Werte ersetzten Feldern darstellt.

Temporal.ZonedDateTime.prototype.withCalendar() Experimentell

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

Temporal.ZonedDateTime.prototype.withPlainTime() Experimentell

Gibt ein neues Temporal.ZonedDateTime-Objekt zurück, das diese Datum-Zeit mit völlig durch die neue Zeit ersetzten Zeitanteil darstellt (in einer Form, die durch Temporal.PlainTime.from() konvertierbar ist).

Temporal.ZonedDateTime.prototype.withTimeZone() Experimentell

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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4