Date.parse()
Methode liest eine String-Repräsentation eines Datums ein und gibt die Anzahl der Millisekunden seit dem 1. Januar 1970 00:00:00 UTC oder NaN
, wenn der String kein Datum ist oder manchmal wenn einige Datums- oder Zeitwerte einen falschen Wert haben (z. B. 2015-02-31), zurück.Date.parse
Methode einzusetzten, weil das Einlesen von Strings implementierungsabhängig war. Es sind sehr viele Unterschiede wie verschiedene Implementierungen strings einlesen, weshalb Strings manuell eingelesen werden sollten (eine Bibliothek kann helfen, wenn viele Formate eingesetzt werden sollen).Syntax
Direkter Aufruf:
Date.parse(dateString)
Impliziter Aufruf:
new Date(dateString)
Parameter
dateString
- Ein String, der ein RFC2822 or ISO 8601 Datumsformat (mit Zeit) repräsentiert (andere Formate können manchmal eingesetzt werden, jedoch ist das Ergebnis manchmal unerwartet).
Rückgabewert
Eine Zahl, die die Millisekunden zwischen dem 1. Januar 1970 00:00:00 UTC und dem Datum, das in dem übergebenen Parameter repräsentiert wird. Wenn der Parameter kein valides Datum repräsentiert, wird NaN
zurückgegeben.
Beschreibung
Die parse()
Methode bekommt ein Datumsstring (z. B. "Dec 25, 1995"
) und gibt die Anzahl der Millisekunden seit dem 1. Januar 1970 00:00:00 UTC zurück. Diese Funktion ist nützlich, um Datumswerte mithilfe eines Stringswertes einzustellen, (z. B. im zusammenhang mit der setTime()
Methode und dem Date
Objekt).
Bei einer Stringrepräsentation mit einer Zeitm, gibt die parse()
Methode die Zeitwert zurück. Es wird die RFC2822 / IETF Datums Syntax (RFC2822 Section 3.3) unterstützt (z. B. "Mon, 25 Dec 1995 13:30:00 GMT"
). Die Methode versteht die kontimentalen US Zeitzonenabkürzungen, jedoch sollte lieber der Zeitzonenunterschied angegeben werden, wie zum Beispiel "Mon, 25 Dec 1995 13:30:00 +0430"
(4 Stunden und 30 Minuten östlich vom Greenwich Meridian).
GMT und UTC werden gleich berücksichtigt. Die lokale Zeitzone wird eingesetzt um Argumente im RFC2822 Kapitel 3.3 Format zu interpretieren, welche keine Zeitzoneninformationen enthalten.
Wegen der Unterschiede beim einlesen von Datums Strings, ist es empfohlen das Einlesen eines Datums immer manuell durchzuführen, wenn das Ergebnisse inkonsistent sind, besonders über verschiedene ECMAScript Implementierungen hinweg, wo Strings wie "2015-10-12 12:00:00"
manchmal zu NaN
, UTC oder lokaler Zeitzone eingelesen werden.
ECMAScript 5 ISO-8601 Format Unterstützung
Der Datums- / Zeit-String ist manchmal in ISO 8601 Format. Zum Beispiel können "2011-10-10"
(nur ein Datum) oder "2011-10-10T14:48:00"
(Datum und Zeit) übergeben und eingelesen werden. Wenn der String ein ISO 8601 Datum (ohne Zeit) ist, wird die UTC Zeitzone eingesetzt, um die Argumente zu interpretieren. Wenn der String Datums- und Zeitangaben im ISO 8601 Format enthällt, wird dieses als lokale Zeit interpretiert.
Weil Zeitzonen im String enthalten sein können und interpretiert werden können, wird immer die Anzahl der Millisekunden zwischen dem repräsentierten Datum und dem 1. Januar 1970 00:00:00 UTC oder NaN
zurückgegeben.
Weil parse()
eine statische Methode von Date
ist, wird diese mit Date.parse()
aufgerufen und nicht als Methode einer Date
Instanz.
Unterschiede in erwarteten Zeitzonen
Wenn der Datumsstring "March 7, 2014"
gegeben ist, nimmt parse()
dabei die lokale Zeitzone an. Ist hingegen ein ISO Format wie "2014-03-07"
angegeben, so wird eine UTC Zeitzone angenommen (ES5 und ECMAScript 2015). Deshalb können die so erstellten Date
Objekte einen unterschiedlichen Zeitpunkt repräsentieren. Dieses ist von der ECMAScript Version abhängig wenn das System mit einer lokalen UTC Zeit eingestellt ist. Das bedeutet, dass zwei Strings mit einem äquivalenten Datum (Unterschied in der Formatierung) zu zwei verschiednenen Ergebnissen führen kann.
Fall-back für implementierungsspezifische Datumsformate
Die ECMAScript Spezifikation besagt: Wenn ein String nicht dem Standardformat entspricht, nutzen die Funktionen eine Fall-back-Lösung in Form einer implementierungsabhängigen Heuristik oder eines implementierungsabhängigen Algorithmus. Unkenntliche Strings oder Daten, die nicht valide Werte von ISO formattierten Elementen haben, führen dazu, dass Date.parse()
den Wert NaN
zurückgibt.
Immer, wenn ein String kein ISO Format hat (ECMA-252) und nicht valide Datumswerte hat, ist es vom Wert und vom Browser abhängig, ob NaN
zurückgegeben wird oder nicht. Z. B.:
// Kein-ISO String: Mit nicht validen Datumswerten
new Date('23/25/2014');
Führt zu den Datum 25. November 2015 (Ortszeit) in Firefox 30 und zu einem nicht validen Datum in Safari 7. Immer, wenn Strings als ISO Format erkannt werden und diese nicht valider Werte enthalten, wird von allen Browsern, die mindestens ES5 unterstützen, NaN
zurückgegeben:
// ISO String mit nicht validen Werten
new Date('2014-25-23').toISOString();
// returns "RangeError: invalid date" in all es5 compliant browsers
SpiderMonkey's implementierungsabhängige Heuristik kann in der jsdate.cpp
-Datei gefunden werden. Der String "10 06 2014"
ist ein Beispiel für einen nicht konformen ISO formatierten String und dieses wird durch die implementierungsabhängige Heuristik abgearbeitet. Siehe zudem diese grobe Übersicht an, wie das Analysieren funktioniert.
new Date('10 06 2014');
Wird das Datum 6. Oktober 2014 (Ortszeit) erzeugen und nicht den 10 Juni 2014. Andere Beispiele:
new Date('foo-bar 2014').toString();
// returns: "Invalid Date"
Date.parse('foo-bar 2014');
// returns: NaN
Beispiele
Einsatz von Date.parse()
Wenn IPOdate
ein existierendes Date
Objekt ist, kann es auf den 9. August 1995 (Ortszeit) gesetzt werden:
IPOdate.setTime(Date.parse('Aug 9, 1995'));
Das gleich Beispiel für das Analysieren von nicht-Standarddatumsstrings:
Date.parse('Aug 9, 1995');
Gibt den Wert 807937200000
in der Zeitzone GMT-0300 zurück und andere Werte in anderen Zeitzonen, wenn im String keine Zeitzone definiert ist und es kein ISO formatiertes Datum ist. Deswegen wird als Standardwert die Ortszeit genutzt.
Date.parse('Wed, 09 Aug 1995 00:00:00 GMT');
Gibt 807926400000
in allen Zeitzonen zurück, weil GMT (UTC) angegeben ist.
Date.parse('Wed, 09 Aug 1995 00:00:00');
Gibt den Wert 807937200000
in der Zeitzone GMT-0400 zurück und andere Werte in anderen Zeitzonen, wenn im String keine Zeitzone definiert ist und es kein ISO formatiertes Datum ist. Deswegen wird als Standardwert die Ortszeit genutzt.
Date.parse('Thu, 01 Jan 1970 00:00:00 GMT');
Gibt 0 in allen Zeitzonen zurück, weil GMT (UTC) angegeben ist.
Date.parse('Thu, 01 Jan 1970 00:00:00');
Gibt den Wert 14400000
in der Zeitzone GMT-0400 zurück und andere Werte in anderen Zeitzonen, wenn im String keine Zeitzone definiert ist und es kein ISO formatiertes Datum ist. Deswegen wird als Standardwert die Ortszeit genutzt.
Date.parse('Thu, 01 Jan 1970 00:00:00 GMT-0400');
Gibt 14400000
in allen Zeitzonen zurück, weil GMT (UTC) angegeben ist.
Spezifikationen
Spezifikation | Status | Kommentar |
---|---|---|
ECMAScript 1st Edition (ECMA-262) | Standard | Initiale Definition. Implementiert in JavaScript 1.0. |
ECMAScript 5.1 (ECMA-262) Die Definition von 'Date.parse' in dieser Spezifikation. |
Standard | ISO 8601 Format hinzugefügt. |
ECMAScript 2015 (6th Edition, ECMA-262) Die Definition von 'Date.parse' in dieser Spezifikation. |
Standard | |
ECMAScript 2017 Draft (ECMA-262) Die Definition von 'Date.parse' in dieser Spezifikation. |
Entwurf |
Browserkompatibilität
Feature | Chrome | Firefox (Gecko) | Internet Explorer | Opera | Safari |
---|---|---|---|---|---|
Basic support | (Ja) | (Ja) | (Ja) | (Ja) | (Ja) |
ISO 8601 format | (Ja) | 4.0 (2.0) | 9 | (Ja) | (Ja) |
Feature | Android | Chrome for Android | Firefox Mobile (Gecko) | IE Mobile | Opera Mobile | Safari Mobile |
---|---|---|---|---|---|---|
Basic support | ? | (Ja) | (Ja) | ? | ? | ? |
ISO 8601 format | ? | (Ja) | (Ja) | ? | (Ja) | (Ja) |
Kompatibilitätsnotitzen
- Firefox 49 (Firefox 49 / Thunderbird 49 / SeaMonkey 2.46) hat das Einlesen von 2-Stelligen Jahreszahlen geändert und hat sich damit an den Google Chrome angepasst und nicht mehr an den Internet Explorer. Jetzt werden 2-Stellige Jahreszahlen, die kleiner oder gleich 50 sind zum 21. Jahrhundert gezählt. Zum Beispiel wird
04/16/17
jetzt zum 16. April 19 2017 und nicht mehr zum 16. April 1917 eingelesen. Es vermeidet alle Probleme mit mehrdeutigen Jahren. Es wird empfohlen das ISO 8601 (z. B. 2017-04-16) zu benutzen (Bug 1265136).