世界を動かす技術を、日本語で。
ここにはたくさんの驚きがあるね！一般的なテーマは、パーサーが入力を日付として解釈しようとすごく意欲的で、かなり無原則な方法でもそうしているってことかな。人間のユーザーがその解釈に同意しないような状況でも、エラーを示す方法もあるのにね。ただ、変なケースのいくつかは、実際のユニークな利用ケースに起因しているのかもしれないね！
問題は、これらを全部推測し始めることができないってことだね。完全にランダムなノイズだよ。32から49の文字列は2000年代だけど、50以降は1900年代だし。全部消して、やり直した方がいいよ。
10/28。悪くないね。でも、実装による部分もありそうだね： https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
その通りだよ。特定のバージョンのNodeと特定のタイムゾーンで質問を確認したって最初に小さく書いておいたのは、両方とも重要だからね。
17/28の結果について、嬉しいのか恥ずかしいのか分からないな。なんでこんなことを知ってるんだろう？息子はjs Dateの経験がないのに11/28で結構満足してたよ。前の回答から推測したみたい。タイプ強制についても説明したけど、ITのキャリアを諦めさせちゃったかもしれないな。
JSクイズをクリックするのはいつも楽しいよ。もう10年以上JSをプログラミングしてるけど、正規表現で確認してないものをDateでパースする勇気はなかったな。
本当にそうだね。10年間セキュリティのJSコードを書いてた。標準が多くのアップデートを受け始めた頃だよ。私たちのシステムは、ブラウザ間で安全（かつ予測可能）に動作するもののほんの小さなサブセットだった。アップデート後も、取り入れたのはarray.filterとstructuredCopyだけ。他は本当にメリットがなく、攻撃面を増やすだけだった。そしてTypeScriptが登場。JSの歴史の中で最大のチャンスを逃した感じだね。今でも、良いJSを書くには、言語の1%しか使えないってことを知って、その使い方に気を使うことが大事だよ。
で、今は二つの問題があるね。
面白いクイズだし、驚くような挙動もたくさんある。でも、実用的な観点から見ると、あんまり重要じゃないと思う。自分のユースケースが本当にローカルタイムを気にするのかよく考えて、インスタントを適切にする方法を見つけてみて。そしたら、UTC ISO 8601の文字列やUnixタイムスタンプに従って、ほとんどの複雑さが消えるか、少なくともソフトウェアの小さな部分に収まるよ。これがいつも可能とは限らないのは分かってるけど（1-5時のローカルタイムをまたぐ休憩をユーザーに取らせる機能をサポートしなきゃいけなかったことがあって、DSTの境界付近は本当に大変だった） - でも、少なくとも私の経験では、ほとんどの時間で気にする範囲を最小限に抑える方法が見つかるよ。もし生の/検証されていないユーザー入力を日付パーサーに渡してるなら、それは間違ってるよ。
それに同意するよ。慣れてないと簡単にハマる罠だと思うし、このクイズが多くの人にとって役立つきっかけになればいいな。 :)
「生の/検証されていないユーザー入力を日付パーサーに渡しているなら、持ち方が間違ってるよ。」その通りだね。こんな風にDateクラスを使うなんて思いもしなかった。挙動がかなり変だし、ローカルタイムは複雑になることもあるけど、曖昧な文字列を渡して正しい時間が得られるとは思わないよ。
ユーザー入力を検証された入力に変える正しい方法は「パース」することだから、言語機能の「日付パーサー」に渡すのは全然合理的なことだよね。これがうまくいかないのは、JavaScriptプログラマーにはあまり驚かれないだろうね。