new Date("wtf") - ¿Qué tan bien conoces la clase Date de JavaScript?

• Este quiz se enfoca en cómo se comporta la clase Date de JavaScript ante distintos tipos de entrada
• Incluye experimentos sobre el resultado que devuelve la clase Date, si lanza excepciones y cómo procesa internamente valores de entrada inesperados para el usuario (por ejemplo, "wtf")
• A través de este quiz, se pueden entender fácilmente los momentos excepcionales de JavaScript Date, su estrategia de parsing, el incumplimiento del estándar y otros patrones de comportamiento inesperados
• Su objetivo es mejorar la comprensión de desarrolladores de JavaScript y responsables de testing para reducir errores en el manejo de fechas e incertidumbre que pueden surgir en programas reales

[GN⁺]

Opiniones de Hacker News

• En mi consola de JS de firefox salen respuestas distintas a las de este quiz
• Ojalá dejaran de burlarse de JavaScript. Ya antes la gente hacía eso y luego salió Node, y ahora está por todo el mundo
  • TypeScript probablemente sea la mejor opción entre los lenguajes por los que te pueden pagar
  • Me recuerda al meme de WAT, que durante casi 10 años la gente tomó como si el undefined behaviour fuera una prueba definitiva de la falta de sentido de la tecnología. En realidad, la gente simplemente malentendía el concepto de tecnología. No es gracioso que no puedas contener agua con un ladrillo, pero por alguna razón todos esperaban que JavaScript detectara todos los ~errores~ como errores o que los corrigiera por sí solo. Es una buena meta, pero si eso no es posible, también era rara esa idea de presumirlo con orgullo. Siento que ese ambiente duró demasiado tiempo
• Me parece un quiz divertido. Hay muchos comportamientos sorprendentes. Pero en la práctica siento que en general importa poco. En situaciones reales, primero habría que pensar si de verdad necesitas la hora local y si conviene usar instantes como unidad. Si usas cadenas UTC ISO 8601 o Unix timestamp, la mayor parte de la complejidad desaparece, o al menos solo hay que lidiar con ella en una parte del software. Claro, no siempre es así (una vez tuve que cubrir dos franjas de descanso del usuario, de 1 a 5, y en el límite de DST fue una pesadilla). Aun así, por experiencia, en la mayoría de los casos sí se puede encontrar una manera de minimizar el área que requiere atención. Si pasas entrada del usuario sin ninguna validación directamente a un date parser, ese uso está mal
  • Como precisamente parsear es convertir la entrada del usuario al formato correcto, me parece razonable pasársela al date parser que da el lenguaje. El hecho de que eso no funcione bien no creo que sorprenda mucho a los programadores de JavaScript
  • Estoy totalmente de acuerdo con que “no debes pasar entrada del usuario sin validar a un date parser”. Pero la diferencia entre una API bien hecha y una que no lo está es que una buena API falla de inmediato si algo está mal y te dice “lo estás usando mal”. Si hay algo aunque sea un poco raro, debería fallar correctamente; no debería intentar procesar datos extraños como sea. Creo que el problema es que muchas APIs de JS están diseñadas para funcionar pase lo que pase. No quiero que salga NaN ni conversiones ambiguas de strings
  • Cada vez que alguien dice “solo usa cadenas UTC ISO 8601 o Unix timestamp”, me da la impresión de que esa persona solo ha trabajado con fechas de una forma muy limitada. Basta pensar en qué pasa con fechas futuras. Por ejemplo, si dices “nos vemos a las 7 de la noche”, lo importante es verse a las 7 aunque cambie el horario de verano o se modifique la hora. Y eso pasa seguido en la vida real. De hecho es un problema más sutil. En algunas apps, el contexto de la zona horaria es indispensable. Por ejemplo, si muestras reservaciones de restaurantes, debe verse en la hora local del restaurante, no en la del usuario. Lo importante es la hora “de allá”, no dónde estoy yo ahora. O sea, GMT/UTC no es la cura mágica para todos los problemas de fechas. Para fechas pasadas sí puede ser una buena solución, pero incluso ahí muchas veces ayuda guardar también la hora local del usuario o la zona horaria del momento en que ocurrió el evento
  • También me parece buena idea dar una opción para especificar explícitamente el offset de DST. En algunos casos sirve bastante. Siempre me ha confundido que Excel no infiera por sí solo el formato cuando usa CSV
  • Estoy de acuerdo con esto. Es una trampa en la que los principiantes pueden caer fácilmente, y ojalá este quiz haga que más gente lo piense dos veces
• ¡Hay muchísimas partes sorprendentes! Siento que, en general, el parser se esfuerza demasiado por interpretar la entrada dada como si fuera una fecha. Aunque esa interpretación no tenga mucho principio, o incluso sea tan rara que ni un usuario humano estaría de acuerdo, parece que igual intenta forzarle un significado. Incluso cuando realmente no puede interpretarlo, da la impresión de que no aprovecha activamente las formas de señalar error. Claro, tal vez estos casos tan extraños vengan de usos raros del mundo real
  • Siento que este comportamiento es literalmente imposible de predecir. Es ruido casi aleatorio. Las cadenas del 32 al 49 salen en los 2000, mientras que a partir de la 50 se interpretan como 1900. En casos así, lo correcto sería tirarlo todo y hacerlo de nuevo
  • Entiendo ese impulso de querer escribir código que siempre produzca un resultado válido. Pero la mayoría de nosotros ha podido contener ese impulso. Me pregunto por qué quienes diseñaron esto no pudieron hacerlo
  • Este fenómeno es un problema común en desarrolladores con algunos años de experiencia. El junior solo ve errores y está ocupado haciendo que apenas funcione. El mid-level se obsesiona con la idea de “reduzcamos los errores como sea”, así que el parser hace demasiadas suposiciones. Por eso terminas con algo como la clase Date. El senior conoce muy bien el riesgo de esos errores y diseña de forma consistente y robusta para que la entrada incorrecta falle de inmediato
• Saqué 17/28. De verdad... ¡qué preguntas tan malditas! Creo que ya va siendo hora de echarle un vistazo a esto de Temporal
  • Sí que se está tardando muchísimo en salir. Si lees la actualización más reciente, hasta da un poco de risa: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes
• Saqué 10/28. No está tan mal, pero creo que el resultado puede variar según la implementación: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
  • Me salió 17/28 y no sé si sentirme orgulloso o avergonzado. Ni yo sé por qué conozco estas cosas. Mi hijo no tiene nada de experiencia con JS Date, pero solo viendo las respuestas anteriores e infiriendo sacó 11/28. Yo le expliqué qué es la coerción de tipos. Entonces me dio la impresión de que quizá le arruiné la carrera en TI a mi hijo
  • De verdad varía según la implementación. Puse adrede al inicio del quiz que estaba verificado en una versión específica de Node y una zona horaria específica; ambas influyen mucho en el resultado
  • Vi que al principio del quiz el autor especificó la zona horaria exacta de su laptop. Creo que una de las que fallé fue por no fijarme en eso. Me parece una explicación totalmente válida. Siento que debí haber notado desde el principio que eso iba a ser clave
• En JS uso cadenas iso para las fechas, porque está lleno de trampas peligrosas. (Basta con ver incluso las primeras preguntas del quiz). Las alternativas populares como Moment también tienen problemas graves en varios sentidos. Mezclan los conceptos de “date”, “time” y “datetime”, y eso genera todavía más confusión. También he oído explicaciones que dicen que no debería existir esa distinción entre “time” y “date”, pero eso no coincide en nada con mi experiencia
  • Librerías conocidas como Moment, Luxon y Day.js cometen el error de manejar distintos conceptos del tiempo (tiempo absoluto, tiempo civil, etc.) como si fueran un solo objeto. ¿De verdad el tiempo absoluto y el tiempo civil son lo mismo? Intentan forzarlo todo a una sola cosa
• Mi puntuación fue... 28 de noviembre de 2000... creo
  • Me reí muchísimo con eso
• Algo que me intriga es cómo terminó pasando algo así. Parece el resultado de novatos que armaron con prisa un montón de heurísticas incoherentes que ni siquiera se pueden mezclar entre sí. Pero en realidad no debió ser obra de principiantes, así que me pregunto qué llevó a que quedara así
  • Ya lo mencionaron en otros comentarios, pero Brendan Eich dijo directamente en Twitter (enlace) que simplemente copiaron el comportamiento de la clase Date de Java. Ese contexto histórico me parece fascinante
  • En la práctica, la mayoría de los problemas vienen de intentar parsear a la fuerza strings rarísimos que no tienen nada que ver con fechas. Casi todo son edge cases. Claro, sería mejor que en esos edge cases simplemente diera error de forma más consistente, pero salvo que estés metiendo cualquier string escrita por el usuario directamente a Date.parse(), no es un problema tan grave. En la práctica terminas usando una librería especializada para fechas. Porque ni siquiera las partes decentes de Date son tan buenas
  • Cuando un lenguaje permite operator overriding o no tiene tipos estáticos, a veces un mismo método termina teniendo que comportarse de 10 maneras distintas para usos completamente distintos. Java y C++ también tienen bastantes APIs así de inconsistentes (aunque no tan grave como JS)
• Los quizzes de JS tienen ese encanto de que uno entra para reírse. Llevo más de 10 años usando JS y nunca he parseado con Date un string sin validarlo con regex antes
  • Entonces terminas creando dos problemas
  • Me identifico con eso. Durante 10 años escribí código JS relacionado con seguridad. Fue justo cuando el estándar estaba recibiendo actualizaciones grandes. Nuestro sistema solo usaba una parte realmente pequeña que funcionaba de forma consistente y predecible entre navegadores. Incluso después de cambiar el estándar, solo añadimos array.filter y structuredcopy; todo lo demás lo ignoramos porque no daba beneficios reales y solo ampliaba la superficie de ataque. Luego llegó TypeScript, y creo que fue la mayor oportunidad desperdiciada en la historia de JS. Incluso hoy, programar bien en JS significa, en la práctica, usar con muchísimo cuidado solo el 1% del lenguaje. Y ni siquiera eso deja de requerir mucha cautela