自分のパソコンでは出ていた日付が、iPhoneでは「Invalid Date」になっていた

記事の一覧に「3日前」「先週」といった表示を出そうと思って、投稿日をJavaScriptで扱う処理を書いた。
自分のパソコンでは、狙いどおりに出た。
その日の夜、スマホで同じページを開いたら、日付のところに「Invalid Date」と出ていた。
書き間違いを探して、しばらく無駄な時間を使った。

渡していた文字列が、そもそも読めていなかった

僕が書いていたのは、こういう一行だった。
new Date('2026-08-24 10:30:00')
データベースから取り出した日時の形をそのまま渡していた。

この形は、日付と時刻のあいだが半角スペースになっている。
実はこの書き方、JavaScriptの決まりごとの中には入っていない。
読めるブラウザもあれば、読めないブラウザもある、という宙ぶらりんな状態だった。
僕のパソコンのブラウザは親切に解釈してくれていて、スマホのSafariは解釈しなかった。
それだけの違いで、片方だけ壊れて見えていた。

スラッシュに変えると直る。でも直った理由が弱い

検索するとすぐ「スラッシュ区切りにすれば通る」と出てくる。
new Date('2026/08/24 10:30:00')
たしかにこれで、手元でもスマホでも表示された。

ただ、これも決まりごとで保証された書き方ではなくて、たまたま多くのブラウザが受け付けているだけだった。
今日動いているのは分かるけれど、明日も動く根拠がない。
そういう直し方は、後でまた同じ場所で転ぶ。

決まりごとに沿った形は、日付と時刻を大文字のTでつなぐものだった。
new Date('2026-08-24T10:30:00')
スペースをTに置き換えるだけで、どのブラウザも同じ読み方をしてくれる。

Tを付けたら、今度は9時間ずれた

安心したのも束の間で、末尾にZを付けた書き方を見つけて真似したら、表示が9時間ずれた。
'2026-08-24T10:30:00Z'のZは、世界標準時という意味だった。
日本時間の10時半のつもりで渡した値が、日本時間の19時半として表示されていた。

これは他人事ではなくて、僕は同じずれで一度つまずいている。
手元の開発環境のサーバーが世界標準時で動いていて、本番のサーバーが日本時間で動いていた。
予約投稿した記事が、手元では時間になっても出てこないのに、本番では出ている。
バグを疑って中身を読み返したけれど、原因はコードではなく、時計のほうだった。

いまは、日付の解釈をJavaScriptに任せない

あれから方針を変えて、画面に出す文字はサーバー側で作るようにした。
「2026年8月24日」と書かれた文字列を、そのまま受け取って、そのまま出す。
JavaScriptに渡すのは、計算が必要なときだけにした。

計算が要るときも、文字列ではなく数値で渡している。
1970年からの経過秒を数字で渡せば、書き方の揺れが入り込む余地がない。
HTMLのほうにものように、機械が読むための値を別に置いた。
人が読む文字と、機械が読む値を、はじめから分けて持つ。

今回いちばん効いたのは、直し方そのものより、確認の仕方を変えたことだった。
自分のパソコンで表示された時点で「動いた」と判断していたのが、そもそもの入口だった。
日付まわりを触った日は、必ずスマホでも開く。
それだけで、この手の見落としはずいぶん減った。