new Date("wtf") - JavaScriptのDateクラスをどれだけよく知っているか？

• このクイズは、JavaScriptのDateクラスがさまざまな入力状況でどのように動作するかに焦点を当てている
• ユーザーが予想しない入力値（例: "wtf" など）が入ったときに、Dateクラスが返す結果、例外の有無、内部の処理方式などの実験内容を含む
• このクイズを通じて、JavaScript Dateの例外的な瞬間、パース戦略、標準非準拠など、予想外の動作パターンを簡単に把握できる
• JavaScript開発者およびテスト担当者が、実際のプログラムで発生しうる日付処理エラーと不確実性を減らすための理解を深めることが目的

[GN⁺]

Hacker Newsの意見

• 自分の firefox JS コンソールでは、このクイズとは違う答えが出る
• JavaScriptをあまりバカにしないでほしい。昔もみんながそうしていたら、その後 Node が登場して、今では世界中に広がった
  • TypeScript は、おそらくお金をもらって使える言語の中では最高の選択肢だと思う
  • ほぼ10年にわたって、人々が undefined behaviour をまるで技術の無意味さの決定的証拠のように扱っていた WAT ミームを思い出す。実際には、単に人々が技術という概念を誤解していただけだ。レンガで水を入れられないのは笑い話ではないのに、なぜかみんな JavaScript ならあらゆる ~ミス~ を全部エラーにするか、自動で直してくれるはずだと期待していた。良い目標ではあるが、それが不可能ならむしろ誇るべきだ、というような見方もどこかおかしかった。こうした空気が長く続きすぎたと感じる
• 面白いクイズだと思う。驚くような挙動も多い。でも実際には、たいていはそれほど重要ではないとも感じる。 実際の場面では、本当にローカル時刻が必要なのか、まず instant 単位で扱うのが適切かを考えてほしい。UTC ISO 8601 文字列や Unix timestamp を使えば、複雑さの大半は消えるか、少なくともソフトウェアの一部だけで気にすれば済む。もちろん常にそうとは限らない（以前、ユーザーの休憩時間が1〜5時の2区間を含まなければならないケースがあって、DST 境界では本当に大変だった）。それでも、ほとんどの場合は気にすべき領域を最小化する方法を見つけられるというのが自分の経験だ。 何の検証もしていないユーザー入力を date parser にそのまま渡すなら、その使い方自体が間違っている
  • ユーザー入力を正しい形式に変換する方法こそが パース なのだから、言語が提供する date parser に渡すのは理にかなっていると思う。これがうまくいかないこと自体は、JavaScript プログラマーにとってそれほど驚きではないと思う
  • 「何の検証もしていないユーザー入力を date parser に渡すべきではない」という点には完全に同意する。ただ、適切な API とそうでない API の違いは、適切な API は異常があれば即座に失敗して「使い方が間違っている」と教えてくれることだ。少しでもおかしければ、きちんと失敗すべきで、変なデータをどうにか処理しようとしてはいけない。多くの JS API は、何があっても動くように設計されているのが問題だと思う。NaN も見たくないし、中途半端な文字列変換も望んでいない
  • 「UTC ISO 8601 文字列か Unix timestamp だけ使えばいい」と言うたびに、そういう人たちは日付をかなり限定的な形でしか扱ったことがないのだろうと思ってしまう。 未来の日付でその戦略を試したらどうなるか考えてみればいい。たとえば「夜7時に会おう」という約束では、サマータイムが変わったり時刻制度が変わったりしても、7時に会うこと自体が重要だ。こういうことは現実によくある。 実際にはもっと微妙な問題だ。アプリによっては、必ずタイムゾーンの文脈が必要になる。たとえばレストラン予約を表示するサービスなら、ユーザーの現地時刻ではなく、レストランの現地タイムゾーンで表示すべきだ。予約時間で重要なのは「その場所」の時間であって、自分が今どこにいるかではない。 つまり GMT/UTC はすべての日付問題の万能薬ではない。 過去の日付なら良い解決策ではあるが、それでもユーザーの現地時刻やイベント発生時のタイムゾーンを別途保存しておくと役立つことが多い
  • DST オフセットを明示的に指定できるオプションを用意するのも良い方法だと思う。状況によっては有用だ。Excel が CSV を使うときにフォーマットを自動推論しないのも、いつも不思議だった
  • この話には同意する。初心者なら簡単にはまりやすい罠で、このクイズが多くの人にもう一度考えるきっかけになればいいと思う
• 驚く点が本当に多い！ 全体としては、パーサーが与えられた入力を何とか日付として解釈しようと、過剰に頑張っているように見える。その解釈がまったく筋が通っていなかったり、人間のユーザーが見ても同意できないほど奇妙だったりしても、無理やり意味を与えている感じだ。実際には解釈できない場面でも、エラーを示す方法はあるのに、それを積極的に使っていない印象がある。もちろん、もしかすると奇妙なケースの一部は現実の変わったユースケースから来ているのかもしれないが
  • こういう挙動は予測不可能だと感じる。ほとんどランダムなノイズだ。32〜49番の文字列までは 2000 年代として出るのに、50 番以降は 1900 年代として解釈される。 こういうときは、全部捨てて作り直すのが正しいと思う
  • 何が何でも有効な結果を返すコードを書きたくなる気持ちはわかる。 でも大半の人は、その衝動を抑えられる。これを設計した人たちは、なぜ抑えられなかったのか不思議だ
  • この現象は、実務経験が数年ある開発者によく見られる問題だ。 ジュニア開発者は、エラーが出るのを見て、とにかく動かすことに必死になる。 ミッドレベル開発者は「とにかくエラーを減らそう」という考えに執着して、パーサーが過剰に多くを仮定する。だから Date クラスのような現象が生まれる。 シニア開発者は、この種のエラーの危険性を身に染みて知っていて、一貫性があり robust な設計にし、間違った入力は即エラーにするよう書く
• 17/28 点だった。本当に……呪われた問題ばかりだと思う！ そろそろこの Temporal stuff も見てみるべき時期なのかもしれない
  • あれは本当にリリースまで時間がかかっているようだ。最新アップデートを読むと少し笑ってしまう: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes
• 10/28 点だった。悪くはないけれど、実装ごとに結果が違う可能性があると思う: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
  • 17/28 だったけど、誇るべきなのか恥ずかしがるべきなのかわからない。こんなことをなぜ知っているのか自分でも不思議だ。うちの息子は JS Date の経験がまったくないのに、ただ前の答えを見て推測しながら 11/28 を取った。型変換が何かは自分が説明した。そうしているうちに、自分は息子の IT の進路を邪魔してしまったのではないかという気がしてきた
  • 本当に実装ごとに違う。クイズの冒頭に、特定の Node バージョンと特定のタイムゾーンで検証したとわざわざ書いておいたが、その両方が結果に大きく影響する
  • クイズの冒頭で、作者が自分のノート PC の正確なタイムゾーンを明記していたのを見た。間違えた問題のひとつは、それを気にしなかったせいだと思う。確かにもっともな説明だ。始める前から、そういうことが重要になると気づくべきだったという気もする
• JS では日付に iso 文字列を使う。危険な落とし穴があまりにも多いからだ（クイズの最初の数問を見るだけでもわかる）。Moment などの人気代替ライブラリも、多くの面で同じくらい深刻な問題を抱えている。"date"、"time"、"datetime" という概念を混同して、さらに大きな混乱を招いている。「"time" と "date" という区別は不要だ」というような説明も聞いたことがあるが、自分の経験とはまったく合わない考えだ
  • Moment、Luxon、Day.js のような有名ライブラリは、別個の時間概念（絶対時間、市民時間など）をひとつのオブジェクトで扱うという過ちを犯している。絶対時間と市民時間が同じものだとでもいうのか。無理にひとつにまとめようとしている
• 自分のスコアは……2000年11月28日……だった気がする
  • これを見てしばらく笑ってしまった
• ひとつ気になるのは、どうしてこんなことになったのかという点だ。本当に、初心者が寄ってたかって急ごしらえした、一貫性もなく、互いに混ぜることすらできないあらゆるヒューリスティックが乱立した結果のように見える。でも実際には初心者の仕事ではなかったはずで、何がこんな状況を生んだのか気になる
  • 別のコメントでも触れられていたが、Brendan Eich が Twitter で（リンク）自ら、Java の Date クラスの挙動をそのままコピーしたのだと述べていた。自分にはこういう歴史的文脈が興味深い
  • 実際のところ、問題の大半は日付とまったく関係ない変な文字列を無理やりパースしようとしたときに起きている。ほとんどが edge case だ。もちろん、edge case ではもっと一貫してエラーだけを返すほうが望ましいが、ユーザー入力の任意の文字列を Date.parse() にそのまま渡すのでなければ、それほど問題にはならない。実際には専用の日付ライブラリを使うことになる。Date のまともな部分ですら、そこまで優れているわけではないのだから
  • 言語で operator overriding が可能だったり静的型がなかったりすると、ひとつのメソッドが 10 通りもの異なる用途に合わせて動かなければならないことがよくある。Java や C++ にも、こういう一貫性のない API はかなりある（とはいえ JS ほど深刻ではない）
• JS クイズは、笑うためにクリックする楽しさがある。10年以上 JS を使ってきたが、regex で検証していない文字列を Date にパースしたことはない
  • そうすると問題を2つ作ることになる
  • 似たような共感がある。10年間、セキュリティ関連の JS コードを書いてきた。標準が大きく更新される頃だった。自分たちのシステムでは、ブラウザごとに一貫して予測可能に動く本当に小さな部分しか使わなかった。標準変更後も array.filter と structuredcopy だけ追加し、残りは実質的な利益もなく攻撃対象領域を増やすだけだったので全部無視した。 そして TypeScript が出てきたが、JS の歴史における最大の機会損失だったと思う。 今でも JS でまともにコーディングするというのは、実際には言語の 1% だけを注意深く使うことだ。それですら慎重でなければならない