Date sai de cena e Temporal chega

 (piccalil.li)
6 pontos por GN⁺ 2026-01-13 | 1 comentários | Compartilhar no WhatsApp
  • Aponta a incompletude e inconsistência do objeto Date existente no JavaScript e apresenta a API Temporal como substituta
  • Date funciona como um objeto mutável (mutable object), destoando do conceito real de data, e tem problemas estruturais como erros de parsing e limitações no tratamento de fuso horário
  • Temporal oferece um novo modelo de tratamento de data e hora baseado em imutabilidade, incluindo classes detalhadas como PlainDate, ZonedDateTime e Duration
  • Os métodos de Temporal não modificam o objeto existente e retornam um novo objeto, permitindo operações de encadeamento mais claras e seguras
  • Temporal está atualmente no estágio 3 de padronização (Stage 3) e já conta com suporte experimental em navegadores modernos como Chrome e Firefox

Problemas do objeto Date no JavaScript

  • O construtor Date causa confusão por causa de regras de parsing inconsistentes e indexação pouco intuitiva
    • Exemplo: o mês (month) começa em 0, mas o dia (day) e o ano (year) começam em 1
    • Strings como "99" são interpretadas como 1999, enquanto "100" vira o ano 0100, mostrando a falta de consistência
  • Date foi projetado com foco em tempo (time) e é armazenado internamente como timestamp Unix (em milissegundos)
  • O suporte a fuso horário (time zone) é limitado e não reconhece horário de verão (DST) nem calendários não gregorianos
  • Por essas limitações, é comum depender de grandes bibliotecas de terceiros como Moment.js e date-fns, o que pode levar a queda de desempenho

O conflito entre imutabilidade e referência

  • No JavaScript, valores primitivos (primitive) são imutáveis e armazenados como o próprio valor, enquanto objetos (object) são armazenados por referência (reference) e podem ser alterados
  • Date é um objeto criado por meio de um construtor (constructor), portanto é mutável
    • Exemplo: ao chamar setMonth() ou setDate(), o objeto original é alterado diretamente
  • Isso causa mudanças de valor inesperadas entre variáveis que referenciam o mesmo objeto
    • Exemplo: se uma função recebe today como argumento e modifica a data internamente, o today original também é alterado

Temporal: a nova API de data e hora

  • Temporal é um objeto de namespace (namespace object), não um construtor, com uma estrutura semelhante à de Math
    • Principais componentes: PlainDate, PlainDateTime, PlainTime, ZonedDateTime, Duration, Now etc.
  • Temporal.Now retorna o momento atual em vários formatos
    • plainDateISO() → data no formato ISO
    • zonedDateTimeISO() → data e hora com fuso horário
  • Os objetos de Temporal oferecem um conjunto de métodos mais claro
    • Operações explícitas por unidade com add({ days: 1 }), subtract({ years: 2 }) etc.
    • Mantêm a imutabilidade ao retornar um novo objeto sem modificar o anterior

Como Temporal funciona e suas vantagens

  • Os objetos de Temporal continuam sendo objetos, mas seguem um padrão de uso imutável intencional
    • Exemplo: today.add({ days: 1 }) retorna um novo objeto de data, e o today original não é alterado
  • Oferece uma sintaxe mais concisa e clara em comparação com Date
    • Exemplo: 
      const today = Temporal.Now.plainDateISO();  
console.log(`Tomorrow will be ${ today.add({ days: 1 }) }. Today is ${ today }.`);  
// 결과: Tomorrow will be 2026-01-01. Today is 2025-12-31.
  • Atende a demandas modernas como definição de fuso horário, cálculo de períodos e manutenção do formato ISO
  • Com encadeamento de métodos como add, subtract, since e until, é possível expressar cálculos complexos de data de forma concisa

Situação da padronização e perspectivas

  • Temporal chegou ao estágio 3 da proposta do ECMAScript (Stage 3), fase em que a implementação nos navegadores é recomendada
  • O suporte experimental já começou em Chrome e Firefox, e outros navegadores também devem adotá-lo
  • Os desenvolvedores já podem participar da melhoria da especificação por meio de testes e feedback
  • Date continuará existindo, mas a perspectiva é que Temporal se torne a forma padrão de lidar com datas no futuro
  • O texto conclui dizendo que “deveria ter sido substituído em 1995, mas mesmo agora Temporal.Now é o momento ideal”

Leituras relacionadas

1 comentários

 
GN⁺ 2026-01-13
Comentários do Hacker News

  • Este texto trata de vários comportamentos absurdos do construtor Date do JavaScript
    Em especial, explica o problema de o formato 'YYYY-MM-DD' ser interpretado como meia-noite em UTC, fazendo a data ficar deslocada em um dia nos fusos locais
    Originalmente, na ISO 8601, quando não há fuso especificado, deveria ser considerado o horário local, mas por um erro durante a redação da especificação do ES5 isso passou a ser tratado como “Z” (UTC)
    Depois tentaram corrigir no ES2015, mas como inúmeros sites dependiam do comportamento antigo e incorreto, a mudança foi revertida por causa da compatibilidade com a web
    Para mais detalhes, veja a seção Broken Parser

    • Teria sido ótimo se existisse uma diretiva 'strict datetime', como 'use strict'
      Assim daria para aplicar o comportamento correto de forma opcional, sem criar problemas de incompatibilidade com código legado
      Ou então poderia existir algo como import Date from 'browser:date', trazendo um objeto global corrigido por meio de um módulo interno
    • Eu mesmo, no passado, já separei strings manualmente para criar um objeto de data sem fuso horário
      Não faz sentido que um valor que representa apenas uma data, como aniversário, mude por causa do fuso
      Lembro que antigamente o Outlook salvava aniversários com fuso horário, então toda vez que eu mudava de país o aniversário andava um dia
    • A expressão “foi sacrificado no altar da compatibilidade com a web” chama atenção
      Mas haveria alternativa? Forçar ramificações por versão de navegador, como na época do IE5, provavelmente teria sido ainda pior
    • No site jsdate.wtf dá para experimentar na prática os comportamentos bizarros do JS Date
    • Quando se pensa que esses problemas são a origem de inúmeros bugs pequenos, é algo ao mesmo tempo engraçado e triste

  • Tenho muita inveja de como Rails e Ruby tratam tempo e datas
    APIs como Time.current.in_time_zone('America/Los_Angeles') + 3.days - 4.months + 1.hour são intuitivas e poderosas
    Ruby sobrecarrega o objeto Time como um único objeto consistente, então quase não é preciso se preocupar com conversões ou casting
    Fico pensando como seria bom poder escrever algo simples como new Date().add({ days: 1 }) no JS

    • Mas há quem questione se uma sintaxe como “3.days - 4.months + 1.hour” é realmente boa
      Também é discutível se sobrecarregar a biblioteca padrão é mesmo a melhor abordagem

  • É uma pena que o Safari ainda não ofereça suporte à API Temporal
    Espero que isso aconteça no ano que vem

  • O Date do JavaScript tem muitos problemas, mas acho que o fato de ser um objeto em si não é um grande problema
    Seria melhor se fosse imutável, mas não é surpresa que um objeto mutável seja alterado

    • O problema é que outro código pode alterar implicitamente o objeto Date que eu estava usando
      O verdadeiro perigo da mutabilidade aparece em mudanças não locais

  • É incômodo que a API Temporal não trate de forma alguma informações sobre segundos bissextos (leap second)
    Quero criar uma ferramenta JS para cálculos astronômicos, mas conversões para UTC exigem dados de segundos bissextos
    Existem alternativas como temporal-tai, mas isso é inconveniente porque é preciso manter o arquivo de segundos bissextos no cliente
    Por causa da SOP (política CORS), também não dá para buscar o arquivo diretamente de um site externo
    Os navegadores são atualizados periodicamente, então fica a dúvida de por que não embutem essas informações

    • É um mal-entendido achar que a SOP bloqueia o arquivo de segundos bissextos
      Se o servidor definir o cabeçalho Access-Control-Allow-Origin ou fornecer isso no formato de arquivo JS, funciona
      Ainda assim, incluir e manter dados de segundos bissextos no próprio navegador pode ser uma tarefa custosa
    • Dizer que “só lida com UTC” não é uma descrição precisa
      UTC, por definição, inclui segundos bissextos, então o mais correto é dizer que na prática isso lida apenas com tempo POSIX

  • No exemplo de código, deveria dizer que a interpretação como anos da década de 1900 começa em "50", e não em "33" — é só uma correção de typo

  • Estou usando o polyfill do Temporal e, até agora, estou bastante satisfeito

    • Mas ele tem 51 KB, então não é exatamente leve (link do bundlephobia)
      Para servidores ou apps grandes, tudo bem, mas em apps pequenos isso pode pesar
    • Também apareceu a pergunta de como ele se compara com moment ou luxon

  • Estranhamente, o texto não menciona Date.now() em momento nenhum
    Para comparar com Temporal, deveria ter explicado a partir de Date.now()
    Essa função retorna o tempo decorrido em milissegundos desde 1º de janeiro de 1970
    Temporal tem uma API mais amigável, mas no fundo a proposta é expressar a distância relativa no tempo

    • Mas também existem os bugs relacionados a timestamp citados no texto
      Então fica a dúvida de como converter para o formato desejado sem passar por Date

  • Foi deixada uma correção pequena, mas importante: o certo é “daylight saving time”, e não “daylight savings time”

  • Até agora eu não sabia que o JS Date era tão bagunçado assim

    • O mais triste é que esses problemas já estavam claramente visíveis desde 1995
      Se tivessem tido um pouco mais de cuidado naquela época, muitos desenvolvedores não teriam caído nessas armadilhas