new Date("wtf") – Wie gut kennst du die Date-Klasse von JavaScript?

• Dieses Quiz konzentriert sich darauf, wie sich die Date-Klasse von JavaScript bei unterschiedlichen Eingaben verhält
• Enthalten sind Experimente dazu, welches Ergebnis die Date-Klasse zurückgibt, ob Ausnahmen auftreten und wie die interne Verarbeitung aussieht, wenn unerwartete Eingabewerte eingegeben werden (z. B. "wtf")
• Mit diesem Quiz lassen sich die Ausnahmemomente von JavaScript Date, Parsing-Strategien, fehlende Standardkonformität und andere unerwartete Verhaltensmuster leicht nachvollziehen
• Ziel ist es, das Verständnis von JavaScript-Entwicklern und Testverantwortlichen zu verbessern, um Fehler bei der Datumsverarbeitung und Unsicherheiten, die in realen Programmen auftreten können, zu verringern

[GN⁺]

Hacker-News-Kommentare

• In meiner Firefox-JS-Konsole kommen andere Antworten heraus als in diesem Quiz.
• Ich wünschte, man würde nicht immer auf JavaScript herumhacken. Früher haben Leute das auch getan, und dann kam Node heraus und jetzt ist es überall auf der Welt verbreitet.
  • Ich denke, TypeScript ist wahrscheinlich die beste Wahl unter den Sprachen, für deren Einsatz man bezahlt werden kann.
  • Das erinnert mich an das WAT-Meme, bei dem Leute fast 10 Jahre lang undefined behaviour als endgültigen Beweis für die Sinnlosigkeit von Technik im Allgemeinen betrachtet haben. Tatsächlich haben die Leute einfach das Konzept von Technik missverstanden. Dass man mit einem Ziegelstein kein Wasser aufbewahren kann, ist nicht lustig, aber irgendwie erwarteten alle, dass JavaScript jeden einzelnen ~Fehler~ entweder als Fehler abfängt oder von selbst korrigiert. Das ist zwar ein gutes Ziel, aber wenn es unmöglich ist, war es auch eine seltsame Haltung, darauf noch stolz zu sein. Ich habe erlebt, dass diese Stimmung viel zu lange angehalten hat.
• Ich finde, das ist ein unterhaltsames Quiz. Es gibt viele wirklich überraschende Verhaltensweisen. Aber in der Praxis halte ich das meist nicht für besonders wichtig. In realen Situationen sollte man sich zuerst fragen, ob man wirklich lokale Zeit braucht und ob es sinnvoll ist, mit Instants zu arbeiten. Mit UTC-ISO-8601-Strings oder Unix-Timestamps verschwindet der Großteil der Komplexität, oder man muss sich zumindest nur in einem Teil der Software darum kümmern. Natürlich nicht immer so (ich hatte einmal den Fall, dass die Ruhezeit eines Nutzers die beiden Intervalle 1–5 Uhr abdecken musste, und an der DST-Grenze war das die Hölle). Trotzdem ist es meiner Erfahrung nach in den meisten Fällen möglich, einen Weg zu finden, den Bereich zu minimieren, um den man sich kümmern muss. Ungeprüfte Nutzereingaben direkt an den Date-Parser zu übergeben, ist schlicht eine falsche Verwendung.
  • Da das Umwandeln von Nutzereingaben in ein korrektes Format genau Parsing ist, finde ich es vernünftig, sie an den vom Sprachstandard bereitgestellten Date-Parser zu übergeben. Dass das nicht gut funktioniert, dürfte JavaScript-Programmierer nicht besonders überraschen.
  • Ich stimme völlig zu, dass man „ungeprüfte Nutzereingaben nicht an einen Date-Parser übergeben“ sollte. Aber der Unterschied zwischen einer guten und einer schlechten API ist, dass eine gute API bei Problemen sofort fehlschlägt und dir sagt: „Du verwendest das falsch.“ Sobald irgendetwas auch nur ein bisschen merkwürdig ist, sollte sie sauber fehlschlagen, statt zu versuchen, irgendwie seltsame Daten zu verarbeiten. Ich glaube, viele JS-APIs sind das Problem, weil sie so entworfen wurden, dass sie unter allen Umständen irgendwie funktionieren. Ich will weder NaN noch halbherzige String-Konvertierungen.
  • Jedes Mal, wenn jemand sagt: „Benutz einfach UTC-ISO-8601-Strings oder Unix-Timestamps“, denke ich, dass diese Leute Datumswerte nur auf sehr eingeschränkte Weise behandelt haben. Man muss nur daran denken, wie diese Strategie bei zukünftigen Datumswerten funktioniert. Zum Beispiel ist bei einer Verabredung wie „Treffen wir uns um 19 Uhr“ wichtig, dass man sich um 19 Uhr trifft, auch wenn sich Sommerzeit oder Uhrzeitregelungen ändern. Solche Dinge passieren in der Praxis oft. Tatsächlich ist das Problem noch subtiler. In manchen Apps braucht man zwingend den Kontext einer Zeitzone. Wenn ein Dienst zum Beispiel Restaurantreservierungen anzeigt, sollte er die lokale Zeit des Restaurants zeigen, nicht die lokale Zeit des Nutzers. Bei der Reservierungszeit ist die Zeit „dort“ wichtig, nicht wo ich mich gerade befinde. GMT/UTC ist also kein Allheilmittel für alle Datumsprobleme. Für vergangene Datumswerte ist es zwar eine brauchbare Lösung, aber auch dann ist es oft hilfreich, zusätzlich die lokale Zeit des Nutzers oder die Zeitzone zum Zeitpunkt des Ereignisses zu speichern.
  • Ich denke, es ist auch gut, Optionen anzubieten, mit denen sich der DST-Offset explizit festlegen lässt. Das kann je nach Situation nützlich sein. Ich fand es bei Excel immer verwirrend, dass es bei CSV das Format nicht selbst ableitet.
  • Dem stimme ich zu. Das ist eine Falle, in die Einsteiger leicht tappen, und ich hoffe, dass dieses Quiz viele Leute dazu bringt, noch einmal darüber nachzudenken.
• Es gibt extrem viele überraschende Stellen! Der grobe Eindruck ist, dass der Parser sich übermäßig bemüht, die gegebene Eingabe irgendwie als Datum zu interpretieren. Selbst wenn diese Interpretation völlig prinzipienlos oder sogar so seltsam ist, dass nicht einmal menschliche Nutzer zustimmen würden, scheint er ihr zwanghaft irgendeine Bedeutung zu geben. Selbst in Situationen, in denen er eigentlich nicht interpretieren kann, gäbe es Wege, einen Fehler zu signalisieren, aber davon wird anscheinend kaum aktiv Gebrauch gemacht. Natürlich kann es auch sein, dass diese merkwürdigen Fälle aus seltsamen realen Anwendungsfällen stammen.
  • Dieses Verhalten fühlt sich völlig unvorhersehbar an. Es ist eher zufälliges Rauschen. Strings von 32 bis 49 werden als 2000er-Jahre interpretiert, ab 50 dagegen als 1900er-Jahre. In so einem Fall sollte man meiner Meinung nach einfach alles abreißen und neu bauen.
  • Ich kann den Impuls nachvollziehen, Code so zu schreiben, dass immer ein gültiges Ergebnis herauskommt. Aber die meisten von uns konnten diesen Impuls unterdrücken. Deshalb frage ich mich, warum die Leute, die das entworfen haben, das nicht konnten.
  • Das ist ein typisches Problem bei Entwicklern mit ein paar Jahren Berufserfahrung. Junior-Entwickler sehen nur Fehler und sind schon froh, wenn überhaupt etwas läuft. Midlevel-Entwickler verbeißen sich in die Denkweise „Wir müssen Fehler um jeden Preis reduzieren“, wodurch der Parser viel zu viele Annahmen trifft. So entstehen Phänomene wie die Date-Klasse. Senior-Entwickler kennen die Risiken solcher Fehler sehr genau und entwerfen daher konsistent und robust, sodass falsche Eingaben sofort einen Fehler auslösen.
• Ich habe 17/28 Punkte erreicht. Wirklich ... verfluchte Aufgaben! Vielleicht ist jetzt der Zeitpunkt gekommen, mir dieses Temporal-Zeug einmal anzusehen.
  • Es dauert wirklich ewig bis zur Veröffentlichung. Wenn man das neueste Update liest, ist es schon ein bisschen komisch: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes
• Ich habe 10/28 richtig. Nicht schlecht, aber ich denke, die Ergebnisse können je nach Implementierung unterschiedlich ausfallen: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
  • Bei mir kamen 17/28 heraus, und ich weiß nicht, ob ich stolz oder beschämt sein soll. Ich frage mich selbst, warum ich so etwas überhaupt weiß. Mein Sohn hat überhaupt keine Erfahrung mit JS Date, hat aber einfach aus den vorherigen Antworten extrapoliert und 11/28 erreicht. Ich habe ihm erklärt, was Typumwandlung ist. Da kam mir der Gedanke, ob ich meinem Sohn damit vielleicht eine IT-Karriere verdorben habe.
  • Es hängt wirklich von der Implementierung ab. Ich habe absichtlich ganz am Anfang des Quiz dazugeschrieben, dass ich es mit einer bestimmten Node-Version und in einer bestimmten Zeitzone überprüft habe; beides hat einen wichtigen Einfluss auf die Ergebnisse.
  • Ich habe gesehen, dass der Autor zu Beginn des Quiz die genaue Zeitzone seines Laptops angegeben hat. Eine meiner falschen Antworten lag vermutlich daran, dass ich das nicht beachtet habe. Das ist eindeutig eine plausible Erklärung. Im Nachhinein denke ich, ich hätte schon vor dem Start merken sollen, dass genau so etwas wichtig werden würde.
• Für Datumswerte in JS verwende ich ISO-Strings, weil es so viele gefährliche Fallstricke gibt. (Das sieht man schon an den ersten paar Fragen des Quiz.) Beliebte alternative Bibliotheken wie Moment haben in vieler Hinsicht genau dieselben gravierenden Probleme. Sie vermischen die Konzepte „date“, „time“ und „datetime“ und sorgen damit für noch mehr Verwirrung. Ich habe sogar schon Erklärungen gehört, nach denen es eine Unterscheidung zwischen „time“ und „date“ gar nicht geben sollte, aber das passt überhaupt nicht zu meiner Erfahrung.
  • Bekannte Bibliotheken wie Moment, Luxon und Day.js machen den Fehler, unterschiedliche Zeitkonzepte (absolute Zeit, bürgerliche Zeit usw.) in einem einzigen Objekt zu behandeln. So nach dem Motto: Ist absolute Zeit nicht einfach dasselbe wie bürgerliche Zeit? Sie versuchen, das gewaltsam in eins zu pressen.
• Meine Punktzahl ist ... glaube ich ... der 28. November 2000.
  • Darüber musste ich lange lachen.
• Eine Sache, die mich interessiert, ist: Wie konnte es überhaupt so weit kommen? Es sieht wirklich aus wie das Ergebnis eines Haufens absoluter Anfänger, die hastig eine inkonsistente Sammlung von Heuristiken gebaut haben, die nicht einmal miteinander kombinierbar sind. Aber in Wirklichkeit war das ja wohl nicht das Werk von Einsteigern, also frage ich mich, was zu dieser Situation geführt hat.
  • Wurde auch in anderen Kommentaren erwähnt: Brendan Eich hat auf Twitter direkt gesagt (Link), dass man das Verhalten der Date-Klasse aus Java einfach kopiert hat. Diesen historischen Kontext finde ich faszinierend.
  • Praktisch alle Probleme entstehen dadurch, dass völlig merkwürdige Strings zwanghaft geparst werden, die mit Datumswerten eigentlich gar nichts zu tun haben. Das sind fast nur Edge Cases. Klar wäre es besser, in solchen Fällen konsistenter einfach Fehler zu werfen, aber wenn man nicht gerade beliebige Nutzereingaben direkt in Date.parse() kippt, ist das kein allzu großes Problem. In der Praxis benutzt man ohnehin spezialisierte Datumsbibliotheken. Selbst die brauchbaren Teile von Date sind nicht besonders großartig.
  • Wenn eine Sprache Operator Overloading erlaubt oder keine statischen Typen hat, kommt es oft vor, dass eine einzelne Methode 10 völlig verschiedene Zwecke bedienen soll. Auch in Java oder C++ gibt es einige solche inkonsistenten APIs (wenn auch nicht so schlimm wie in JS).
• Auf JS-Quizze klickt man gern, um zu lachen. Ich benutze JS seit über 10 Jahren, aber ich habe noch nie einen nicht per Regex validierten String als Date geparst.
  • Dann schafft man nur zwei Probleme.
  • Fühle ich ähnlich. Ich habe 10 Jahre lang sicherheitsrelevanten JS-Code geschrieben. Das war ungefähr zu der Zeit, als der Standard stark erweitert wurde. Unser System nutzte nur einen wirklich winzigen Teil, der in allen Browsern konsistent und vorhersehbar funktionierte. Auch nach den Änderungen des Standards haben wir nur array.filter und structuredcopy hinzugefügt; den Rest haben wir ignoriert, weil es praktisch keinen Nutzen brachte und nur die Angriffsfläche vergrößerte. Dann kam TypeScript, und ich denke, das war die größte verpasste Chance in der Geschichte von JS. Auch heute bedeutet „richtig“ in JS zu programmieren im Grunde, nur 1 % der Sprache vorsichtig zu benutzen. Selbst das muss man mit Bedacht tun.