日付パースは「文字列 → Date オブジェクト」への変換作業
日付・時間ユーティリティの中でも 日付パース(date parsing)は、業務で非常に重要な処理です。 API から受け取った日付、ユーザー入力の文字列、CSV の日付列など、 「文字列として渡される日付」を JavaScript の Date オブジェクトに変換する必要がある場面は数えきれません。
しかし、日付パースは初心者が最もつまずきやすい領域でもあります。 理由は、JavaScript の日付パースが 形式によって挙動が変わるためです。 ISO 形式なら正しく動く一方、非標準形式ではブラウザ差異が出たり、Invalid Date になったりします。
ここでは、日付パースの基本から、業務で使えるテンプレートまでを丁寧に解説します。
JavaScript の日付パースの基本:new Date(string) と Date.parse()
JavaScript で日付文字列をパースする最も基本的な方法は次の 2 つです。
new Date("2024-04-01")(ISO 8601 形式推奨)
const d = new Date("2024-04-01");
console.log(d);
JavaScriptISO 8601(YYYY-MM-DD や YYYY-MM-DDTHH:mm:ssZ)はもっとも安全で、 ほぼすべての環境で正しく解釈されます。
ただし注意点があります。
ISO 日付のみ(時刻なし)は UTC として解釈される
new Date("2024-04-01"); // UTC の 2024-04-01 00:00:00 として扱われる
JavaScriptJST(UTC+9)環境では、前日として表示されることがあります。 これは業務で非常に多いバグの原因です。
Date.parse("2024-04-01T00:00:00+09:00")
const ts = Date.parse("2024-04-01T00:00:00+09:00");
console.log(ts); // ミリ秒のタイムスタンプ
JavaScriptDate.parse() はミリ秒のタイムスタンプを返します。 比較や差分計算に便利ですが、非標準形式では NaN を返すことがあります。
非標準形式は危険:ブラウザ差異が発生する
次のような形式は環境によって解釈が異なります。
new Date("2024/04/01"); // 環境によっては Invalid Date
new Date("April 1, 2024"); // Safari で失敗する可能性あり
JavaScriptMDN でも「非標準形式は実装依存であり、互換性がない」と明記されています。 そのため、業務では ISO 形式か手動パースを使うのが安全です。
手動パースは「形式が固定されている場合」に最強
API や CSV で形式が固定されている場合、 もっとも安全なのは split や substring を使った手動パースです。
例:YYYY/MM/DD を手動パースする
function parseSlashDate(str) {
const [y, m, d] = str.split("/").map(Number);
return new Date(y, m - 1, d); // 月は0始まり
}
console.log(parseSlashDate("2024/04/01"));
JavaScript例:YYYYMMDD を手動パースする
function parseCompactDate(str) {
const y = Number(str.slice(0, 4));
const m = Number(str.slice(4, 6));
const d = Number(str.slice(6, 8));
return new Date(y, m - 1, d);
}
console.log(parseCompactDate("20240401"));
JavaScript形式が変わらないなら、この方法がもっとも確実です。
Invalid Date を確実に判定する方法
new Date("invalid") は Invalid Date を返しますが、 文字列比較では判定できません。
正しい判定方法は次の通りです。
function toDate(str) {
const d = new Date(str);
return isNaN(d.getTime()) ? null : d;
}
console.log(toDate("2024-04-01")); // 正常
console.log(toDate("not a date")); // null
JavaScriptgetTime() が NaN なら無効です。
業務で使える「日付パースユーティリティ」テンプレート
業務では複数形式を扱うことが多いため、 次のようなユーティリティを用意しておくと便利です。
export const DateParseUtil = {
// ISO 形式(最も安全)
parseIso(str) {
const d = new Date(str);
return isNaN(d.getTime()) ? null : d;
},
// YYYY/MM/DD
parseSlash(str) {
const parts = str.split("/").map(Number);
if (parts.length !== 3) return null;
const d = new Date(parts[0], parts[1] - 1, parts[2]);
return isNaN(d.getTime()) ? null : d;
},
// YYYYMMDD
parseCompact(str) {
if (str.length !== 8) return null;
const y = Number(str.slice(0, 4));
const m = Number(str.slice(4, 6));
const d = Number(str.slice(6, 8));
const date = new Date(y, m - 1, d);
return isNaN(date.getTime()) ? null : date;
},
// 汎用パーサ(複数形式を試す)
parseAny(str) {
return (
this.parseIso(str) ||
this.parseSlash(str) ||
this.parseCompact(str) ||
null
);
},
};
JavaScript使い方は次の通りです。
import { DateParseUtil } from "./DateParseUtil.js";
console.log(DateParseUtil.parseAny("2024-04-01"));
console.log(DateParseUtil.parseAny("2024/04/01"));
console.log(DateParseUtil.parseAny("20240401"));
JavaScript日付パースの“実務での落とし穴”を深掘りする
ISO 日付のみは UTC として扱われる(超重要)
new Date("2024-04-01"); // UTC 00:00
JavaScriptJST では 9時間ずれて前日になることがあります。 業務で日付がズレるバグの 7 割はこれが原因です。
非標準形式はブラウザ差異が出る
new Date("2024/04/01") は Chrome では動くが Safari では失敗する可能性があります。 MDN でも「非標準形式は互換性がない」と明記されています。
API の日付は形式がバラバラ
API によっては次のように形式が異なります。
"2024-04-01"(ISO)"2024/04/01"(日本式)"04/01/2024"(米国式)"20240401"(数字のみ)"2024-04-01T15:00:00Z"(UTC)
そのため、複数形式に対応したパーサが必須です。
日付パースを正しく扱うと業務ロジックが安定する
日付パースをユーティリティ化しておくと、次のメリットがあります。
- API 変更や形式変更に強くなる
- ブラウザ差異によるバグが減る
- 日付比較・計算が正確になる
- ログ・レポート・画面表示が安定する
日付は業務システムの「基盤情報」です。 その基盤を正しく扱うために、日付パースユーティリティは欠かせません。
まとめ:日付パースは「形式を理解し、確実に変換する技術」
日付パースは単なる文字列変換ではなく、 形式の違い・タイムゾーン・ブラウザ差異を理解したうえで扱うべき重要な処理です。
ポイントは次の通りです。
- ISO 形式はもっとも安全(
YYYY-MM-DD) - 非標準形式はブラウザ差異が出る
- 手動パースは形式が固定されている場合に最強
Invalid DateはisNaN(date.getTime())で判定する- 業務では複数形式に対応したパーサが必要
日付パースを正しく扱えるようになると、 業務システムの品質が一段上がります。
日付は毎日変わりますが、 その扱い方はユーティリティで統一できます。
