Date.parse()

Baseline 広く利用可能

この機能は広く実装されており、多くのバージョンの端末やブラウザーで動作します。2015年7月以降、すべてのブラウザーで利用可能です。

Date.parse() は静的メソッドで、日時の文字列表現を解釈し、その日付のタイムスタンプを返します。

試してみましょう

// 標準の日付時刻文字列の書式
const unixTimeZero = Date.parse("1970-01-01T00:00:00Z");
// UTCString() に似た標準ではない書式化
const javaScriptRelease = Date.parse("04 Dec 1995 00:12:00 GMT");

console.log(unixTimeZero);
// 予想される結果: 0

console.log(javaScriptRelease);
// 予想される結果: 818035920000

構文

Date.parse(dateString)

引数

dateString

文字列で、日時文字列形式です。さまざまな書式を使用する場合の注意事項については、リンク先の参照をご覧ください。

返値

指定された日時のタイムスタンプを表す数値。 dateString が有効な日時として解釈できない場合、NaN が返されます。

解説

この関数は、 setTime() メソッドと組み合わせて、文字列値に基づいて日時の値を設定する場合などに便利です。

parse() が処理できる書式は明示的に指定されていませんが、いくつかの不変条件があります。

日時文字列の書式（toISOString() によって生成される）に対応している必要があります。
x がミリ秒の値が 0 の日付である場合、 x.valueOf() は、Date.parse(x.toString())、Date.parse(x.toUTCString())、Date.parse(x.toISOString()) のいずれかと同じでなければなりません。これは、 toString() および toUTCString() によって生成される書式も対応している必要があるということです。
仕様上は、 toLocaleString() によって生成される書式化に対応することは要求されていません。ただし、主要なエンジンはすべて toLocaleString("en-US") による書式化に対応しようとしています。

その他の書式は実装によって定義されており、すべてのブラウザーで動作するとは限りません。さまざまな書式に対応する必要がある場合は、ライブラリーが役立ちます。実際、Date.parse() の信頼性の低さが、 Temporal API が導入された理由のひとつです。

parse() は Date の静的メソッドであるため、作成した Date オブジェクトのメソッドとしてではなく、常に Date.parse() として使用します。

例

Date.parse() の使用

以下の呼び出しはすべて 1546300800000 を返します。最初のものは ES5 によれば UTC 時刻を意味し、それ以外は ISO 日付仕様 (Z および +00:00) に従って UTC をタイムゾーンを指定しています。

js
Date.parse("2019-01-01");
Date.parse("2019-01-01T00:00:00.000Z");
Date.parse("2019-01-01T00:00:00.000+00:00");

以下の呼び出しではタイムゾーンを指定していないので、システムの地方時で 2019-01-01 の 00:00:00 に設定されます。

Date.parse("2019-01-01T00:00:00");

toString() および toUTCString() 形式

標準の日付時刻文字列の書式化とは別に、 toString() および toUTCString() の書式化にも対応しています。

js
// toString() 形式
Date.parse("Thu Jan 01 1970 00:00:00 GMT-0500 (Eastern Standard Time)");
// すべての実装で、すべてのタイムゾーンにおける 18000000

// toUTCString() 形式
Date.parse("Thu, 01 Jan 1970 00:00:00 GMT");
// すべての実装で、すべてのタイムゾーンにおける 0

標準外の日付文字列

メモ: この節には、ブラウザーやブラウザーのバージョンによって不整合が生じる可能性のある、実装固有の動作について記載しています。これは、包括的なブラウザーの互換性表を網羅したものではありません。コードで書式を使用する前に、常に自分自身でテストを行ってください。

実装では通常、日付文字列が標準ではない場合、既定で地方時が使用されます。一貫性を保つため、ここでは、実行時が UTC タイムゾーンを使用すると想定し、特に指定がない限り、出力は端末のタイムゾーンによって異なるものとします。地方時の夏時間 (DST) も、これに影響を与える可能性があります。

標準外の日付文字列の例をいくつか挙げます。ブラウザーは日付文字列の解析にとても寛容で、解析できない文字列の部分は破棄する場合があります。互換性の理由から、ブラウザーは互いの動作をコピーすることが多いため、このような処理パターンはブラウザー間で広まる傾向があります。前述のように、次の例はあくまで説明のためのものであり、決して網羅的なものではありません。

説明例 Chrome Firefox Safari

単一の数値	0 （1 桁）	946684800000 (Jan 01 2000); NaN (Firefox ≤122)	-62167219200000 (Jan 01 0000)
	31 （2 桁）	NaN	-61188912000000 (Jan 01 0031)
	999 （3 桁または 4 桁）	-30641733102000 (Jan 01 0999)
さまざまな区切り文字を使用した日時文字列	1970-01-01 （標準）	0 （すべてのタイムゾーン）
	1970/01/01	0
	1970,01,01	0	NaN
	1970 01 01	0	NaN
toString() のような文字列	Thu Jan 01 1970 00:00:00 Thu Jan 01 1970 Jan 01 1970 00:00:00 Jan 01 1970	0
toUTCString() のような文字列	Thu, 01 Jan 1970 00:00:00 Thu, 01 Jan 1970 01 Jan 1970 00:00:00 01 Jan 1970	0
最初の日付成分が 2 桁の場合	01-02-03 （最初の部分は有効な月である可能性がある）	1041465600000 (Jan 02 2003)	-62132745600000 (Feb 03 0001) メモ: Safari は常に YY-MM-DD と推測し、 MM/DD/YY にはなりません。
	27-02-03 （最初の部分は有効な日であるが、月ではない）	NaN	-61312291200000 (Feb 03 0027)
	49-02-03 （最初の部分は有効な日ではなく、 <50）	2495923200000 (Feb 03 2049)	-60617980800000 (Feb 03 0049)
	50-02-03 （最初の部分は有効な日ではなく、 ≥50）	-628300800000 (Feb 03 1950)	-60586444800000 (Feb 03 0050)
範囲を外れた日付成分	2014-25-23 Mar 32, 2014 2014/25/23	NaN
	2014-02-30	1393718400000 (Mar 02 2014)	NaN
	02/30/2014	1393718400000
月名の後の余分な文字	04 Dec 1995 04 Decem 1995 04 December 1995	818031600000
	04 DecFoo 1995	818031600000 最初の 3 文字のみが読み込まれます。 Firefox ≤121 は、有効な月名までを読み込み、 "F" を見つけると NaN を返します。
	04 De 1995	NaN