博士

やあ、ロボ子！今日はJavaScriptの`Date`オブジェクトの面白い挙動について話すのじゃ。

ロボ子

博士、こんにちは。`Date`オブジェクトですか、奥が深そうですね。よろしくお願いします。

博士

そうなのじゃ！例えば、`'2025/05/28'`と`'2025-05-28'`で、JavaScriptの解釈が違うって知ってた？

ロボ子

え、違うんですか？どちらも同じ日付を表しているように見えますが…。

博士

`Date`オブジェクトは、内部的にはタイムスタンプ（エポックからのミリ秒）を保持しているのじゃ。そして、`toDateString()`メソッドはローカル時間を基準に動作する。

ロボ子

なるほど、ローカル時間が関係しているんですね。`'2025-05-28'`の解釈が異なるのは、ブラウザのdate parsingの歴史的経緯が原因とのことですが…。

博士

そう！2009年ごろ、ブラウザは色々な日時フォーマットをサポートしようとしたのじゃ。タイムゾーンオフセットがない場合、ローカルタイムを使うのが一般的だった。

ロボ子

ES5でISO 8601ベースの標準日時フォーマットが導入されたものの、タイムゾーンの解釈は曖昧だったんですね。

博士

その通り！Firefoxはdate-only形式をUTC、date-time形式をローカルタイムとして実装したのじゃ。Chromeも挙動が色々変わったみたい。

ロボ子

Chromeは当初ローカルタイムを使用していたのが、後にUTCに変更、さらにローカルタイムに戻すなど、変遷があったんですね。それは混乱しそうです。

博士

ES6ではタイムゾーンオフセットがない場合はローカルタイムと規定されたけど、ES7でdate-only形式はUTCに戻されたのじゃ。ややこしい！

ロボ子

つまり、ブラウザによって解釈が異なる可能性があるということですね。開発者は注意が必要ですね。

博士

そこで！Temporal APIの登場じゃ！これはタイムゾーンの曖昧さを解消するために、plain dates（タイムゾーンなしの日付）を提供するのじゃ。

ロボ子

Temporal APIですか。日付と時刻の扱いがより明確になるんですね。

博士

Temporalで日付文字列をinstant in timeとして解析する場合、offsetまたはタイムゾーン識別子の指定が必須になるのじゃ。これからは、こっちを使うのがおすすめじゃな。

ロボ子

タイムゾーンを明示的に指定することで、曖昧さをなくせるんですね。勉強になります。

博士

そういうこと！…ところでロボ子、`Date`オブジェクトの挙動がこんなに複雑なの、まるで私の部屋みたいじゃない？

ロボ子

博士の部屋は、確かにカオスですけど…、整理整頓すればきっと`Temporal API`のようにスッキリしますよ！