はじめに
JavaScriptは絶え間ない進化を続けています。これを追いかけていくと、多数の便利な追加や改善の中に、従来のコードが時代遅れになるような、コードの書き方が変わるほどのインパクトある機能を見つけることができます。本連載は、JavaScriptを普段使いする開発者に向けて、JavaScriptの標準規格である「ECMAScript」で標準化された、あるいは標準化予定の機能を紹介しながら、開発者が自身のコードをどうアップデートすべきか解説します。
対象読者
- JavaScriptの最新バージョンの機能を把握したい方
- JavaScriptの経験者で、JavaScriptに改めて入門したい方
- プログラミング言語の最新パラダイムに関心のある方
必要な環境
本記事のサンプルコードは、以下の環境で動作を確認しています。他の環境では動作しないか、動作が不安定になる可能性があります。
-
macOS Sequoia
- Node.js 26.3
Dateの問題点4：日時文字列パースのルールが分かりにくい
日時文字列からDateオブジェクトを生成する文字列パースのルールが、今ひとつ分かりにくい問題があります。
たとえば、以下のリストのように文字列が日付だけなのか、時刻も含むのかで生成される日時が異なります。
const date1 = new Date("2026-06-02");
console.log(date1.toISOString()); // 2026-06-02T00:00:00.000Z
const date2 = new Date("2026-06-02T00:00:00");
console.log(date2.toISOString()); // 2026-06-01T15:00:00.000Z
日付のみで生成するとUTCで午前0時となりますが、時刻まで指定するとそれはローカル時間と解釈され、UTCではマイナス9時間された日時となってしまいます（日本で生成した場合）。
また、RFC 2822形式の文字列も受け入れるので、以下のリストのように月名や曜日を含めたり、スラッシュで区切った文字列も変換できます。ただし、実装によって解釈が変わることがあるので、これも混乱を招きます。
const date3 = new Date("Tue Jun 02 2026");
console.log(date3.toISOString()); // 2026-06-01T15:00:00.000Z
const date4 = new Date("2026/06/02");
console.log(date4.toISOString()); // 2026-06-01T15:00:00.000Z
こちらは時刻を指定していないのに、ローカル時間で解釈されるというのも問題の一つと言えます。
Temporalでは日時文字列の形式はRFC 9557と決まっている
日時文字列のシリアライズ／デシリアライズに使われる形式は、ISO 8601/RFC 3339に基づくRFC 9557で指定されているものを使うことになっています。これにより、パースや文字列化における曖昧さを排除でき、可搬性を向上できます。
RFC 9557に準拠すると、以下の文字列で日時を表現できます。
YYYY-MM-DD T HH:mm:ss.sssssssss Z/±HH:mm [time_zone_id] [u-ca=calendar_id]
以下のリストでは、ナノ秒のセクションこそ省略されていますが、元の文字列と出力の文字列が同じであることを確認できます。
const str = "2026-06-02T10:00:00.000000000+09:00[Asia/Tokyo][u-ca=japanese]"; const date = Temporal.ZonedDateTime.from(str); console.log(date.toString()); // 2026-06-02T10:00:00+09:00[Asia/Tokyo][u-ca=japanese]
常に全部を使うわけではなく、クラスによって省略可能です。ZonedDateTimeでは日時と時差情報は必須ですが、PlainDateでは日付部分のみ、PlainTimeでは時刻部分のみを使います。
