new Date("wtf") - Que savez-vous vraiment de la classe Date de JavaScript ?

• Ce quiz se concentre sur la manière dont la classe Date de JavaScript se comporte face à différents types d’entrée
• Il inclut des expériences sur le résultat renvoyé par la classe Date lorsque des valeurs inattendues sont fournies (par ex. "wtf"), sur l’éventuelle levée d’une exception et sur son mode de traitement interne
• Ce quiz permet de repérer facilement les cas exceptionnels, les stratégies de parsing et les comportements inattendus de JavaScript Date, y compris ses écarts par rapport au standard
• Il vise à améliorer la compréhension des développeurs JavaScript et des testeurs afin de réduire les erreurs de traitement des dates et les incertitudes pouvant survenir dans les programmes réels

[GN⁺]

Commentaires Hacker News

• Dans ma console JS de Firefox, j’obtiens des réponses différentes de celles de ce quiz.
• J’aimerais qu’on arrête de se moquer de JavaScript. Les gens faisaient déjà ça autrefois, puis Node est arrivé, et maintenant c’est partout dans le monde.
  • Je pense que TypeScript est probablement le meilleur choix parmi les langages qu’on peut utiliser en étant payé.
  • Ça me rappelle le mème WAT, qui a duré presque 10 ans, où les gens traitaient l’undefined behaviour comme une preuve définitive de l’inanité de la technologie. En réalité, c’est juste que les gens comprenaient mal ce qu’est une technologie. Ce n’est pas drôle de constater qu’on ne peut pas transporter de l’eau avec une brique, mais bizarrement tout le monde s’attendait à ce que JavaScript détecte toutes les ~erreurs~ ou les corrige tout seul. C’est un bon objectif, mais si c’est impossible, en être fier relevait aussi d’une vision un peu étrange. J’ai eu l’impression que cette ambiance a duré bien trop longtemps.
• Je trouve que c’est un quiz amusant. Il y a plein de comportements surprenants. Mais en pratique, j’ai l’impression que ça n’a généralement pas beaucoup d’importance. Dans un cas réel, il vaudrait mieux se demander d’abord si on a vraiment besoin de l’heure locale, et si travailler au niveau des instants est approprié. Avec des chaînes UTC ISO 8601 ou des timestamps Unix, la majeure partie de la complexité disparaît, ou au moins ne doit être gérée que dans une partie du logiciel. Bien sûr, ce n’est pas toujours le cas (une fois, il fallait que les heures de pause de l’utilisateur couvrent deux créneaux entre 1 h et 5 h, et la frontière DST a été un cauchemar). Malgré tout, d’après mon expérience, il est généralement possible de trouver un moyen de réduire au minimum la zone où il faut s’en préoccuper. Passer directement une entrée utilisateur non validée à un date parser, c’est une mauvaise utilisation.
  • Comme la façon de transformer une entrée utilisateur dans le bon format, c’est justement le parsing, je trouve raisonnable de la passer au date parser fourni par le langage. Le fait que ça marche mal n’est probablement pas très surprenant pour les programmeurs JavaScript.
  • Je suis tout à fait d’accord avec l’idée qu’il ne faut pas passer une entrée utilisateur non validée à un date parser. Mais la différence entre une bonne API et une mauvaise, c’est qu’une bonne API échoue immédiatement quand quelque chose cloche et dit : « tu es en train de mal t’en servir ». Au moindre écart, il faut un échec clair ; il ne faut pas essayer de bricoler avec des données bizarres. Je pense que le problème de beaucoup d’API JS, c’est qu’elles sont conçues pour fonctionner quoi qu’il arrive. Je ne veux pas obtenir NaN, ni voir des chaînes converties de façon bancale.
  • Chaque fois que quelqu’un dit « il suffit d’utiliser des chaînes UTC ISO 8601 ou des timestamps Unix », j’ai l’impression qu’il n’a manipulé les dates que d’une manière très limitée. Il suffit de réfléchir à ce que donne cette stratégie pour des dates futures. Par exemple, pour un rendez-vous « retrouvons-nous à 19 h », ce qui compte, c’est de se retrouver à 19 h même si l’heure change ou si l’heure d’été est modifiée. Ce genre de chose arrive vraiment souvent. En fait, c’est un problème plus subtil que ça. Dans certaines applications, le contexte de fuseau horaire est indispensable. Par exemple, si un service affiche des réservations de restaurant, il faut les montrer dans l’heure locale du restaurant, pas dans celle de l’utilisateur. Ce qui compte, c’est l’heure « là-bas », pas l’endroit où je me trouve maintenant. Autrement dit, GMT/UTC n’est pas le remède universel à tous les problèmes de date. Pour les dates passées, c’est une solution correcte, mais même dans ce cas il est souvent utile de stocker aussi l’heure locale de l’utilisateur ou le fuseau horaire au moment où l’événement s’est produit.
  • Je pense aussi que donner une option pour préciser explicitement l’offset DST est une bonne approche. Selon le contexte, ça peut être utile. J’ai toujours trouvé déroutant qu’Excel n’infère pas lui-même le format quand il utilise du CSV.
  • Je suis d’accord avec ça. C’est un piège dans lequel les débutants peuvent facilement tomber, et j’espère que ce quiz amènera plus de gens à y réfléchir une fois de plus.
• Il y a énormément de choses surprenantes ! Le fil conducteur, selon moi, c’est que le parser essaie beaucoup trop d’interpréter l’entrée fournie comme une date, quoi qu’il arrive. Même quand cette interprétation manque totalement de principes, voire devient étrange au point qu’un humain ne serait pas d’accord, il semble forcer un sens. Même dans les cas où il ne peut pas vraiment interpréter quoi que ce soit, on a des moyens de signaler une erreur, et pourtant on a l’impression qu’il ne les exploite pas activement. Cela dit, peut-être que ces cas bizarres viennent d’usages réels tout aussi bizarres.
  • J’ai l’impression que ce comportement est tout simplement impossible à prédire. C’est à peine mieux qu’un bruit aléatoire. Les chaînes de 32 à 49 donnent des années dans les années 2000, alors qu’à partir de 50 elles sont interprétées dans les années 1900. Dans ce genre de cas, il vaudrait mieux tout jeter et repartir de zéro.
  • Je comprends l’envie d’écrire du code qui produira toujours un résultat valide. Mais la plupart du temps, on arrive à réprimer cette impulsion. Je me demande pourquoi ceux qui ont conçu ça n’y sont pas parvenus.
  • C’est un problème fréquent chez les développeurs avec quelques années d’expérience. Le développeur junior est trop occupé à faire marcher quelque chose malgré les erreurs. Le développeur intermédiaire s’obsède avec l’idée de « réduire les erreurs à tout prix », si bien que le parser fait beaucoup trop d’hypothèses. C’est comme ça qu’on obtient des choses comme la classe Date. Le développeur senior connaît trop bien le danger de ces erreurs, et conçoit donc quelque chose de cohérent et robuste, qui signale immédiatement une erreur en cas d’entrée invalide.
• J’ai eu 17/28. Vraiment… quelles questions maudites ! Il est peut-être temps que je regarde enfin ce truc Temporal.
  • On dirait vraiment que ça prend un temps fou avant de sortir. Les dernières mises à jour sont presque drôles à lire : https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes
• J’ai eu 10/28. Ce n’est pas si mal, mais j’imagine que le résultat peut varier selon l’implémentation : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
  • J’ai eu 17/28 et je ne sais pas si je dois en être fier ou en avoir honte. Je me demande moi-même pourquoi je connais ce genre de choses. Mon fils n’a aucune expérience de JS Date, mais en déduisant à partir des réponses précédentes, il a eu 11/28. Je lui ai expliqué ce qu’est la coercition de type. Du coup, je me demande si je ne viens pas de saboter sa future carrière dans l’IT.
  • Ça dépend vraiment de l’implémentation. J’avais volontairement précisé au début du quiz que je l’avais vérifié avec une version précise de Node et un fuseau horaire précis, car les deux influencent fortement le résultat.
  • J’ai vu qu’au début du quiz, l’auteur indiquait explicitement le fuseau horaire exact de son laptop. Je pense qu’une de mes erreurs vient du fait que je n’y ai pas prêté attention. C’est clairement une explication valable. J’aurais dû comprendre dès le départ que ce serait un élément central.
• En JS, j’utilise des chaînes ISO pour les dates, justement parce qu’il y a trop de pièges dangereux. (On s’en rend compte dès les premières questions du quiz.) Même des bibliothèques alternatives populaires comme Moment posent les mêmes problèmes à bien des égards. Elles mélangent encore plus les concepts de « date », « heure » et « datetime », ce qui crée encore plus de confusion. J’ai même entendu dire qu’il ne devrait pas y avoir de distinction entre « time » et « date », mais ça ne correspond pas du tout à mon expérience.
  • Des bibliothèques connues comme Moment, Luxon ou Day.js ont le tort de traiter des notions temporelles distinctes (temps absolu, temps civil, etc.) comme un seul objet. Comme si le temps absolu et le temps civil étaient la même chose. Elles essaient de tout forcer dans une seule abstraction.
• Mon score, c’est… le 28 novembre 2000… je crois.
  • Ça m’a fait rire pendant un bon moment.
• Une chose que je me demande, c’est comment on a pu en arriver là. On dirait vraiment le résultat précipité d’une bande de débutants, sans cohérence, avec toutes sortes d’heuristiques mélangées qu’on ne peut même pas combiner entre elles. Mais en réalité, ça n’a sûrement pas été fait par des novices, alors je me demande ce qui a conduit à cette situation.
  • Comme cela a été mentionné dans un autre commentaire, Brendan Eich a lui-même expliqué sur Twitter (lien) qu’ils avaient simplement copié le comportement de la classe Date de Java. Je trouve ce contexte historique fascinant.
  • En pratique, la plupart des problèmes viennent du fait qu’on essaie de parser de force des chaînes absurdes qui n’ont rien à voir avec une date. Ce sont presque uniquement des edge cases. Bien sûr, ce serait mieux d’avoir des erreurs plus cohérentes dans ces cas-là, mais si on ne balance pas n’importe quelle chaîne saisie par l’utilisateur directement dans Date.parse(), ce n’est pas si grave. En pratique, on finit par utiliser une bibliothèque de dates spécialisée. Même les parties correctes de Date ne sont pas si excellentes que ça.
  • Quand un langage permet l’operator overriding ou n’a pas de typage statique, il arrive souvent qu’une seule méthode doive couvrir 10 usages différents. Java ou C++ ont aussi pas mal d’API incohérentes de ce type (même si ce n’est pas aussi grave qu’en JS).
• Les quiz JS, c’est toujours amusant à ouvrir pour rigoler. J’utilise JS depuis plus de 10 ans, et je n’ai jamais essayé de parser en Date une chaîne non validée avec une regex.
  • Dans ce cas, on crée juste deux problèmes.
  • Je comprends bien ce ressenti. J’ai écrit du code JS lié à la sécurité pendant 10 ans. C’était à l’époque où le standard évoluait beaucoup. Notre système n’utilisait qu’une toute petite partie du langage, celle qui se comportait de façon cohérente et prévisible sur tous les navigateurs. Même après l’évolution du standard, on n’a ajouté que array.filter et structuredcopy, et on a ignoré tout le reste, faute de bénéfice réel et parce que ça augmentait juste la surface d’attaque. Puis TypeScript est arrivé, et je pense que ça a été la plus grande occasion manquée de l’histoire de JS. Aujourd’hui encore, bien coder en JS, c’est en pratique n’utiliser avec précaution qu’1 % du langage. Et même ça, il faut encore l’utiliser prudemment.