new Date("wtf") - O quanto você conhece a classe Date do JavaScript?

• Este quiz foca em como a classe Date do JavaScript se comporta em várias situações de entrada
• Inclui experimentos sobre o resultado retornado pela classe Date, se há exceção e como funciona o processamento interno quando entram valores inesperados pelo usuário (ex.: "wtf" etc.)
• Com este quiz, é possível entender facilmente os momentos excepcionais do Date em JavaScript, estratégias de parsing, não conformidade com o padrão e outros padrões de comportamento inesperados
• O objetivo é aumentar a compreensão de desenvolvedores JavaScript e profissionais de teste para reduzir erros no tratamento de datas e incertezas que podem surgir em programas reais

[GN⁺]

Opiniões no Hacker News

• No meu console JS do Firefox, saem respostas diferentes das deste quiz
• Eu preferia que não ficassem zoando JavaScript. Antigamente o pessoal fazia isso e aí surgiu o Node, e agora está espalhado pelo mundo inteiro
  • Acho que TypeScript talvez seja a melhor escolha entre as linguagens que você pode usar ganhando dinheiro
  • Isso me lembra o meme WAT, de quase 10 anos atrás, quando as pessoas tratavam undefined behaviour como se fosse prova definitiva da inutilidade da tecnologia. Na verdade, era só um mal-entendido sobre o que a tecnologia é. Não é engraçado que você não consiga carregar água com um tijolo, mas por algum motivo todo mundo esperava que JavaScript detectasse todos os ~erros~ como erro ou os corrigisse sozinho. É um bom objetivo, claro, mas se isso é impossível, também era uma visão meio estranha se orgulhar disso. Já vivi tempo demais nesse tipo de ambiente
• Achei um quiz divertido. Tem vários comportamentos surpreendentes. Mas, na prática, sinto que isso em geral não importa tanto. Em situações reais, eu gostaria que as pessoas primeiro pensassem se realmente precisam de hora local e se faz sentido trabalhar na unidade de instant. Se você usar strings UTC ISO 8601 ou Unix timestamp, a maior parte da complexidade desaparece, ou pelo menos fica confinada a uma parte do software. Claro, nem sempre é assim (uma vez tive que lidar com um intervalo de descanso do usuário que precisava incluir dois blocos entre 1h e 5h, e foi um inferno na virada de DST). Ainda assim, na maioria dos casos, pela minha experiência, dá para encontrar uma forma de minimizar a área que precisa se preocupar com isso. Se você passa entrada do usuário sem validação nenhuma direto para um date parser, está usando errado
  • Como o jeito de converter a entrada do usuário para o formato correto é justamente parsing, acho razoável passá-la para o date parser fornecido pela linguagem. O fato de isso não funcionar bem não deve surpreender muito os programadores de JavaScript
  • Concordo totalmente com a frase “não se deve passar entrada do usuário sem validação para um date parser”. Mas a diferença entre uma API boa e uma API ruim é que a boa falha imediatamente quando há algo estranho e te avisa: “você está usando isso errado”. Assim que houver qualquer anomalia, ela deveria falhar corretamente, e não tentar processar dados esquisitos de qualquer jeito. Acho que o problema de muitas APIs de JS é terem sido desenhadas para funcionar aconteça o que acontecer. Eu não quero NaN, nem conversão meia-boca de string
  • Sempre que alguém diz “é só usar strings UTC ISO 8601 ou Unix timestamp”, eu penso que essa pessoa provavelmente só lidou com datas de um jeito bem limitado. Basta pensar no que acontece com datas futuras se você usar essa estratégia. Por exemplo, um compromisso de “vamos nos encontrar às 19h” depende de ser às 19h, mesmo que mude o horário de verão ou a hora em si. Esse tipo de coisa acontece na vida real com frequência. Na verdade, o problema é mais sutil. Em alguns apps, o contexto de fuso horário é indispensável. Por exemplo, se você mostra reservas de restaurante, deve exibir no horário local do restaurante, não no horário local do usuário. O importante é a hora “de lá”, não onde eu estou agora. Ou seja, GMT/UTC não é cura milagrosa para todos os problemas de data. Para datas passadas, é uma solução aceitável, mas mesmo aí muitas vezes ajuda guardar também a hora local do usuário ou o fuso horário do momento em que o evento ocorreu
  • Também acho uma boa oferecer uma opção para especificar explicitamente o offset de DST. Em alguns contextos isso é útil. Sempre achei confuso que o Excel, ao usar CSV, não infira o formato por conta própria
  • Concordo com isso. É uma armadilha em que iniciantes podem cair facilmente, então espero que este quiz faça bastante gente pensar nisso mais uma vez
• Tem muita coisa surpreendente! O padrão geral, para mim, é o parser se esforçando demais para interpretar a entrada dada como alguma data. Mesmo quando essa interpretação não tem princípio nenhum, ou é tão estranha que nem um humano concordaria, ele parece forçar algum significado. Mesmo quando claramente não consegue interpretar, existem maneiras de sinalizar erro, mas parece que isso não é usado de forma ativa. Claro, talvez alguns desses casos bizarros venham de usos estranhos do mundo real
  • Sinto que esse comportamento é impossível de prever. É praticamente ruído aleatório. As strings 32-49 viram anos 2000, enquanto a partir de 50 são interpretadas como anos 1900. Numa situação dessas, acho que o certo é jogar tudo fora e fazer de novo
  • Eu entendo a vontade de escrever código que sempre produza um resultado válido. Mas a maioria das pessoas conseguiu conter esse impulso. Então eu me pergunto por que quem desenhou isso não conseguiu
  • Isso é um problema comum em desenvolvedores com alguns anos de carreira. O júnior só vê erro e fica ocupado tentando fazer funcionar. O pleno fica obcecado com a mentalidade de “vamos eliminar qualquer erro”, e aí o parser passa a assumir coisas demais. É assim que nasce algo como a classe Date. O sênior conhece na pele o risco desses erros e projeta de forma consistente e robust, fazendo entrada inválida gerar erro imediatamente
• Tirei 17/28. Sério... que perguntas amaldiçoadas! Acho que agora talvez seja a hora de finalmente dar uma olhada nesse lance de Temporal
  • Parece mesmo que isso está demorando demais para ser lançado. Se você ler a atualização mais recente, fica até um pouco engraçado: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes
• Acertei 10/28. Não é tão ruim, mas acho que o resultado pode variar conforme a implementação: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
  • Deu 17/28 e não sei se devo me orgulhar ou ter vergonha. Eu mesmo queria saber por que sei esse tipo de coisa. Meu filho nunca teve experiência nenhuma com JS Date, mas foi inferindo pelas respostas anteriores e tirou 11/28. Eu expliquei para ele o que é coerção de tipo. Aí fiquei pensando se não atrapalhei a carreira dele em TI
  • Realmente varia conforme a implementação. Eu fiz questão de escrever logo no começo do quiz que ele foi validado numa versão específica do Node e num fuso horário específico, porque os dois influenciam bastante o resultado
  • Eu vi que o autor deixou explícito no começo do quiz qual era o fuso horário exato do notebook dele. Acho que errei uma das questões por não prestar atenção nisso. Parece uma explicação totalmente válida. Fico pensando que eu devia ter percebido antes de começar que isso seria importante
• Em JS eu uso strings ISO para datas, porque tem armadilhas perigosas demais. (Dá para ver isso até só nas primeiras perguntas do quiz.) Alternativas populares como Moment também são igualmente problemáticas em vários aspectos. Elas misturam os conceitos de “date”, “time” e “datetime”, criando ainda mais confusão. Já ouvi até explicarem como se não devesse existir distinção entre “time” e “date”, mas isso não bate nem um pouco com a minha experiência
  • Bibliotecas conhecidas como Moment, Luxon e Day.js cometem o erro de tratar conceitos temporais diferentes (tempo absoluto, tempo civil etc.) como um único objeto. Como se tempo absoluto e tempo civil fossem basicamente a mesma coisa. É uma tentativa forçada de juntar tudo
• Minha pontuação foi... 28 de novembro de 2000... eu acho
  • Eu ri muito disso
• Uma coisa que me pergunto é: como isso aconteceu? Parece mesmo o resultado de um monte de iniciantes fazendo às pressas um conjunto inconsistente de heurísticas que nem sequer se misturam direito. Mas não deve ter sido trabalho de novatos, então fico curioso sobre o que levou a esse estado de coisas
  • Já mencionaram isso em outros comentários, mas Brendan Eich falou diretamente no Twitter (link) que simplesmente copiaram o comportamento da classe Date do Java. Para mim, esse contexto histórico é fascinante
  • Na prática, a maior parte dos problemas surge ao tentar fazer parse à força de strings estranhas que não têm nada a ver com data. É quase tudo edge case. Claro que seria melhor ter mais consistência e só retornar erro nesses casos, mas isso não chega a ser um grande problema se você não estiver jogando qualquer string digitada pelo usuário direto em Date.parse(). Na prática, você acaba usando uma biblioteca especializada em datas. Até porque nem as partes boas de Date são assim tão boas
  • Quando a linguagem permite operator overriding ou não tem tipagem estática, às vezes um único método acaba tendo que servir para 10 usos completamente diferentes. Java e C++ também têm várias APIs inconsistentes assim (embora não no mesmo nível do JS)
• Esses quizzes de JS são divertidos de clicar para rir. Uso JS há mais de 10 anos e nunca fiz parse de string com Date sem antes validar com regex
  • Aí você só cria dois problemas
  • Me identifico com isso. Passei 10 anos escrevendo código JS relacionado a segurança, numa época em que o padrão estava passando por grandes atualizações. Nosso sistema usava só uma parte minúscula do navegador, que se comportava de forma consistente e previsível entre navegadores. Mesmo depois das mudanças no padrão, só adicionamos array.filter e structuredcopy; o resto foi ignorado porque não trazia ganho prático e só aumentava a superfície de ataque. E aí apareceu o TypeScript, o que eu considero a maior oportunidade perdida da história do JS. Até hoje, programar direito em JS significa, na prática, usar com muito cuidado só 1% da linguagem. E mesmo isso precisa de cautela demais