こんにちは、KENTEMでフロントエンドを担当しているM.Sです。
普段の開発においてDateオブジェクトの使用は避けては通れないですよね。
皆さんはこのDateオブジェクトの取り扱い（パース）がブラウザ間によって差異があることをご存知ですか？
私はつい先日この事象に遭遇し、結構な時間を吸い取られてしまいました。
今回はこの件についての調査と共有をしていこうと思います。
調査方法
new Date()の引数に思いつく限りのパターンで文字列を格納するnew Date(value).toLocaleDateString()でInvalidDateにならなければ成功- 比較ブラウザはChrome, Firefox（おまけでSafari）
- パターン一覧はコード参照
結果
ブラウザ間で結果が異なります↓
Chromeのみ通るパターン
FirefoxではInvalidDateになる
- 2020 01 01（01と01の間が全角スペース）
- 2020-1（2020-01は通っている）
- 2020/01
- 2020/1
- 2020.01
- 2020.1
- 01-01（2001年扱い）
- 1/1（2001年扱い）
主に全角スペース、ハイフン以外の区切りが認められないようですね。
Firefoxのみ通るパターン
ChromeではInvalidDateになる
- 2020-01-01 25:00:00（1/2であると認識してくれる）
所感
Chromeなら通るのにFirefoxではInvalid Dateになるパターンは私の想像よりも少なかったです。
逆に、この検証をするまではFirefoxでのみ通るケースというのは存在しないと思っていたので意外でした。
(おまけ)Safari
Chromeでは通るのに、SafariではInvalidDateになるパターンです。
- 2020.01.01
- 2020,01,01
- 2020 01 01
- 2020-1-1（2020/1/1は通る）
- 2020.1.1
- 2020,1,1
- 2020 01 01（01と01の間は全角スペース）
- 2020-1（2020-01は通る）
- 2020/01
- 2020/1
- 2020.01
- 2020.1
- 1/1（01-01は通る）
- 01/01
- 1-1
- 2020-01-01 10:00:0
主にハイフン以外の区切り、0埋めしていない値、日付無しが認められないようです。
やはりSafariは他と一線を画す個性的なブラウザですね😇
詰まった事象について
😿「ローカルでは動くのにPlaywrightが落ちる…」
自分で試したらうまくいくのに、Playwrightを実行したら毎回同じテストケースで落ちてしまうという状況に遭遇していました。
原因は、yyyy-MMで渡すべきところを、バックエンドから受け取ったyyyy-Mという書式でそのまま渡していたからでした。
Playwrightは内部的にFirefoxで実行していたのに、自分はChromeを使っていたせいでなかなか気づけなかったです。
まとめ
Chromeは寛容でFirefoxは厳格、Safariは個性的というイメージがあります。
今回の調査を通して、このイメージがより一層明確なものになってしまいました。
また、そもそも文字列を直接 new Date() に渡すのはブラウザ依存になりやすいので避けた方が安心です。
ブラウザ間の挙動に少なからず差異があることを念頭に置き、どのブラウザでも同じ動作を保証できるように開発をすべきだと改めて実感しました。
（Dateオブジェクトの仕様について詳しく知りたい方はこちら）
おわりに
KENTEMでは、様々な拠点でエンジニアを大募集しています！ 建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。 recruit.kentem.jp career.kentem.jp
