JavaScript Temporal está chegando. Datas deixam de ser um atalho frágil.

Quem desenvolve para a web já teve, em algum momento, uma conversa difícil com Date. Parsing inconsistente. Objeto mutável. Fuso horário incompleto. Cálculo atravessando horário de verão que “funciona no meu notebook” e falha em produção.

A MDN publicou que as implementações de JavaScript Temporal começaram a chegar em releases experimentais dos browsers. Ainda estamos longe do suporte estável cross-browser — e a API pode mudar enquanto amadurece. Mesmo assim, vale olhar o que vem aí.

Na minha opinião, essa é uma das atualizações mais positivas do JavaScript em muito tempo. Não é um atalho sintático. É a linguagem assumindo, de forma nativa, um problema que a gente terceiriza há anos para Moment, date-fns e afins.

Highlights

O que mais me chama atenção na proposta:

• Substitui Date de verdade. Temporal não é um patch cosmético. É um modelo novo para instante, relógio de parede, duração e calendário.
• Imutável por padrão. Menos bug de “alguém mutou o objeto no meio do fluxo”. A data que você passa continua sendo a data que você passou.
• Fuso horário de primeira classe. Não só “local vs UTC”. Dá para trabalhar com zonas nomeadas (America/Sao_Paulo, America/New_York) sem reinventar aritmética.
• Calendários além do gregoriano. Hebraico, chinês, islâmico e outros entram pela API, em vez de virarem regra de negócio espalhada no app.
• Durações e comparações explícitas. Temporal.Duration e os métodos compare() deixam ordenação e intervalo legíveis — sem converter tudo para milissegundo na mão.
• Superfície rica, documentação forte. Mais de 200 métodos utilitários e, na mesma onda, centenas de páginas novas na MDN para acompanhar.

Isso não elimina a necessidade de pensar. Elimina a necessidade de carregar uma biblioteca só para fazer o básico com segurança.

O problema que Temporal resolve

O Date do JavaScript herdou o desenho antigo do java.util.Date. A Java corrigiu o seu modelo em 1997. Nós ficamos com a mesma API por quase três décadas.

Na prática, isso significa:

• parsing pouco confiável;
• mutabilidade que esconde efeito colateral;
• suporte limitado a fuso;
• cálculos de DST e calendário histórico difíceis de acertar.

Para produtos com agenda, internacionalização ou qualquer dado sensível a tempo, isso não é detalhe. É risco. Temporal nasce para tornar data e hora previsíveis.

Conceitos que valem gravar

A API separa ideias que Date misturava:

• Temporal.Instant — um ponto único na linha do tempo (timestamp).
• Temporal.ZonedDateTime — data-hora com fuso.
• Temporal.PlainDate / PlainTime / PlainDateTime — “relógio de parede”, sem fingir que já sabe o fuso.
• Temporal.Duration — diferença entre pontos.
• Temporal.Now — o “agora” em formatos e zonas diferentes.

Essa separação é o highlight arquitetural. Em vez de um objeto que tenta ser tudo, você escolhe o tipo que corresponde ao domínio. Agendar um dia de aniversário não é a mesma coisa que marcar um instante absoluto de deploy.

Na prática, o código fica mais honesto

Pegar o “agora” em um fuso específico deixa de ser gambiarra:

const emSaoPaulo = Temporal.Now.plainDateTimeISO('America/Sao_Paulo')

Comparar e ordenar durações também:

const durations = [
  Temporal.Duration.from({ hours: 1 }),
  Temporal.Duration.from({ hours: 2 }),
  Temporal.Duration.from({ hours: 1, minutes: 30 }),
]

durations.sort(Temporal.Duration.compare)

E trabalhar com timestamp Unix — o formato que APIs e bancos ainda usam o tempo todo — fica explícito: instante, agora, duração até o evento. Sem misturar string, número e Date no mesmo fluxo.

Quando o modelo da linguagem acompanha o modelo do problema, a conversa no code review muda. Menos “por que esse getTime()?”. Mais “este valor é instante ou data local?”.

Ainda é experimental — e isso não tira o valor

Firefox Nightly está entre as implementações mais maduras, atrás de preferência. Safari e Chrome têm bugs de tracking abertos — o Can I Use ajuda a acompanhar o suporte. Dá para experimentar com o polyfill @js-temporal/polyfill e pelos docs do TC39.

Eu não colocaria Temporal como dependência crítica de produção em todos os browsers hoje. Colocaria na lista do que o time precisa aprender cedo.

Por quê? Porque a migração mental é maior que a migração de import. Quem continua pensando só em Date vai empurrar o modelo antigo para cima da API nova. Quem já separa instante, zona e duração chega preparado quando o suporte estabilizar.

Minha opinião

Gosto de atualizações que reduzem a distância entre intenção e código. Temporal faz isso.

Em vez de depender de biblioteca para o básico — ou de wrappers internos que cada time reinventa — o runtime passa a oferecer um contrato moderno. Para front-end, isso pesa: formulário de agendamento, contagem regressiva, conteúdo localizado, sync com API. Tudo isso fica menos frágil quando data deixa de ser um objeto mutável com surpresa no parse.

Também gosto do timing da documentação. A MDN não esperou o suporte 100% estável para publicar referência séria. Isso acelera o aprendizado coletivo e reduz o folklore de “Date é assim mesmo”.

Temporal não é hype de sintaxe. É engenharia de plataforma resolvendo uma dívida antiga.

O principal aprendizado?

Datas no JavaScript sempre pediram disciplina. Temporal finalmente oferece um modelo à altura dessa disciplina.

Ainda experimental, ainda em evolução — e, mesmo assim, uma das notícias mais animadoras da plataforma web neste ciclo. Vale ler o post da MDN, experimentar no Nightly ou no polyfill, e começar a desenhar o domínio de tempo do produto com os conceitos certos: instante, zona, duração.

Quando o suporte chegar de verdade, quem já pensou assim só troca a ferramenta. Quem não pensou continua pagando o preço do Date.