A jornada de 9 anos do Temporal para resolver o problema de tempo no JavaScript

 (bloomberg.github.io)
13 pontos por GN⁺ 2026-03-12 | 7 comentários | Compartilhar no WhatsApp
  • A nova especificação Temporal API, que substitui de forma fundamental as limitações do objeto Date no JavaScript, chegou ao ECMAScript Stage 4 após 9 anos de desenvolvimento
  • O Temporal oferece tipos imutáveis, suporte explícito a fuso horário e calendário e precisão em nanossegundos, eliminando a ambiguidade e os erros do Date tradicional
  • Bloomberg, Igalia, Microsoft, Google e Mozilla colaboraram no desenho da especificação e na implementação, viabilizando a cooperação entre múltiplos motores com a biblioteca compartilhada em Rust temporal_rs
  • O Temporal oferece suporte preciso para cálculos temporais e tratamento internacionalizado de calendários por meio de tipos detalhados como ZonedDateTime, Instant, PlainDate/Time e Duration
  • Esse padrão, que resolve problemas acumulados ao longo de 30 anos, é visto como um caso de sucesso de colaboração e inovação aberta no ecossistema JavaScript

Os problemas de tratamento de tempo no JavaScript e a chegada do Temporal

  • O objeto Date existente foi basicamente portado do Date do Java em 1995 e, por conta de mutabilidade, cálculo inconsistente de meses e parsing ambíguo, tem sido fonte de bugs por décadas
    • Ex.: ao usar setMonth, ocorrem erros no cálculo de fim de mês; ao fazer parsing de strings parecidas com ISO, os resultados variam entre navegadores
  • À medida que as aplicações web ficaram mais complexas a partir da década de 2010, as limitações do Date se agravaram
  • Desenvolvedores tentaram contornar o problema com bibliotecas externas como Moment.js, mas isso trouxe aumento do tamanho do bundle e custo de manutenção
  • Em 2017, Maggie Johnson-Pint apresentou a proposta do Temporal ao TC39, dando início à discussão de padronização

Colaboração entre TC39 e a indústria

  • O Temporal começou no Stage 1 em 2018 e, ao longo de 9 anos, chegou ao Stage 4 (padronização)
  • A Bloomberg participou ativamente para resolver problemas de fuso horário e precisão em ambientes JavaScript de grande escala
    • Requisitos: fusos horários personalizados, precisão histórica baseada na IANA e precisão em nanossegundos
  • Houve colaboração com Igalia, Microsoft, Google e Mozilla no desenho da especificação e na implementação
  • Vários engenheiros atuaram como champions, incluindo Philipp Dunkel, Ujjwal Sharma, Philip Chimento, Shane Carr e Justin Grant

Principais tipos e recursos do Temporal

  • Temporal.ZonedDateTime: representação imutável de data e hora com fuso horário, calendário e ajuste de DST explícitos
    • Ex.: na transição de DST em Londres, se 01:30 não existir, o valor é ajustado automaticamente para 02:30
  • Temporal.Instant: representação de um instante absoluto sem fuso horário nem calendário, com precisão em nanossegundos
    • Permite converter o mesmo instante para vários fusos horários
  • PlainDate / PlainTime / PlainDateTime / PlainYearMonth / PlainMonthDay: tipos de “relógio de parede” sem fuso horário
    • Adequados para exibição ou cálculo simples de datas e horários
  • Temporal.Duration: representa intervalos de tempo e permite conversão entre várias unidades (total({ unit: "second" }))
  • Suporte a calendários: executa corretamente operações em calendários não gregorianos, como o calendário hebraico

Implementação e processo de padronização

  • O Temporal é a maior adição de especificação da história do ECMAScript, com cerca de 4.500 casos de teste
  • Foi desenvolvida a implementação compartilhada em Rust temporal_rs, usada em conjunto por V8, Boa e outros motores
    • Vantagens: menor barreira de entrada, manutenção de longo prazo mais fácil e melhor qualidade de código
  • Ao longo de 2024 e 2025, o temporal_rs passou em 100% dos testes e foi avaliado como um caso bem-sucedido de colaboração entre múltiplos motores

Situação de suporte e próximos desafios

  • O Temporal já é suportado em Firefox 139, Chrome/Edge 144 e TypeScript 6.0 Beta
    • O Safari está na fase de Technical Preview, e o Node.js 26 está previsto
  • O próximo desafio é a integração com APIs da web
    • Ex.: suporte a tipos Temporal em elementos de formulário como <input type="date">
    • Também se discute a possibilidade de substituir DOMHighResTimeStamp (com exemplo de uso de Temporal.Now.instant())

Resultados da colaboração e da inovação aberta

  • O Temporal foi concluído como um padrão por meio de 9 anos de colaboração entre múltiplas organizações, com participação de
    • Microsoft, Google, Mozilla, Bloomberg, Igalia e Boa, entre outros
  • O temporal_rs é visto como um caso de sucesso de modelo de infraestrutura compartilhada, demonstrando
    • redução de custos de implementação duplicada, maior consistência e aceleração da inovação
  • O Temporal é avaliado não apenas como uma melhoria de API, mas como prova de colaboração do ecossistema JavaScript para resolver dívida técnica de longo prazo
  • Após 30 anos, o JavaScript finalmente passa a ter uma API moderna de data e hora

Leituras relacionadas

7 comentários

 
jeeeyul 2026-03-12

A complexidade do cálculo do tempo tem muito mais origem na filosofia da humanidade, na precisão da astronomia e na cultura do que em um problema de formato. Fazer contas é fácil até só com long. Historicamente, há muitos pontos na linha do tempo em que 1 + 1 não é 2, e isso se deve em grande parte a calendários, quase como o I Ching, que variam conforme a posição, como o ângulo do Sol e da superfície terrestre. Nesses casos, o calendário lunissolar coreano sequer chegou a ser discutido.

E isso é definido pelo Instituto Coreano de Pesquisa em Astronomia e Ciências Espaciais.
 
tsboard 2026-03-12

Finalmente! Que alegria!!
 
shakespeares 2026-03-12

Finalmente!!
 
roxie 2026-03-12

ZonedDateTime...? Você por acaso...!
 
sea715 2026-03-12

Finalmente
 
click 2026-03-12

time.h de C -> java.util.Date do Java -> Date do JS

joda-time do Java -> JSR 310 -> java.time
-> moment.js -> Temporal do JS

Então foi esse o fluxo.
 
GN⁺ 2026-03-12
Comentários do Hacker News
  • Gosto muito de como o Temporal força você a lidar corretamente com a complexidade do gerenciamento de tempo
    A distinção entre instant e datetime baseado em calendário praticamente evita os erros comuns que aconteciam com Date
    É um pouco verboso, mas ainda assim é muito melhor do que ser chamado às 3 da manhã para corrigir um bug de DST
    • Tecnicamente falando, parece improvável que alguém precise corrigir um bug de DST às 3 da manhã em qualquer dia que não seja domingo
  • Eu também passei por quase 10 anos de sofrimento com parsing de datas ISO8601 em Python
    Um problema aberto em 2012 acabou finalmente entrando na biblioteca padrão como solução
    A discussão relacionada pode ser vista neste tópico do Google Groups
    • Muito obrigado, de verdade. Fazer parsing de datas de outra forma que não seja com fromisoformat agora parece extremamente pouco intuitivo
      Antes eu usava ciso8601, mas depois que entrou no padrão, tudo ficou muito mais simples e estável
  • O fato de o Firefox ter conseguido implementar o Temporal ainda na fase de especificação se deve a André Bargull (Anba), e é especialmente impressionante que ele tenha implementado tudo sozinho como voluntário
  • Temporal é um grande avanço, mas eu ainda não gosto da API
    Eu compartilho código entre cliente e servidor, então tento separar estritamente dados e lógica
    Quero manter todos os dados em JSON puro para facilitar serialização/desserialização, mas os objetos Temporal são instâncias de classe com propriedades de função, o que é inconveniente
    Acho melhor uma abordagem como a do date-fns, em que funções puras são aplicadas a objetos apenas de dados
    • Isso é intencional no design. Os tipos de Temporal são serializáveis, mas não são restaurados automaticamente com JSON.parse
      O desenvolvedor precisa reconstruir manualmente o objeto correto a partir da string ISO
      Automatizar isso traz o risco de lidar com tipos errados
      O exemplo de reviver para Temporal.Instant na documentação pode servir de referência
    • Eu também esbarro nesse problema com frequência. Perder o protótipo com JSON.parse/stringify é uma questão comum
      Mas acho que a escolha da equipe do Temporal foi a correta. Na lógica de data e hora, segurança de tipos é mais importante do que a abordagem simples de dados + funções
      Vincular as operações ao objeto evita que um PlainDate seja tratado por engano como ZonedDateTime
      Em algo como tRPC, basta adicionar uma camada fina para converter nas bordas com Temporal.from() e toString()
      É um pouco incômodo, mas acho melhor do que abrir mão da segurança de tipos
    • Na verdade, instâncias de Date do JavaScript têm o mesmo problema
      Date.toJSON existe, mas ao fazer parse de JSON é preciso converter a string de volta para Date
      Com Temporal é igual, e o date-fns no fim das contas também lida com instâncias nativas de Date
    • Todos os objetos Temporal podem ser serializados/desserializados facilmente com .toString() e Temporal.from()
    • Acho exagerado mudar o JSON.parse para criar objetos Temporal automaticamente
      Assim como com Date, 
      serialize: instant.toJSON()
deserialize: Temporal.Instant.from(jsonDate)
      o certo é tratar isso explicitamente dessa forma
  • Estou muito feliz que o Temporal tenha sido aprovado
    Parabéns a todos os champions que trabalharam nisso por tanto tempo
    Foi divertido trabalhar em temporal_rs nos últimos anos
  • Teria sido interessante mencionar também a trajetória de melhoria da API de tempo no Java (Joda-Time → JSR 310 → Java 8)
    Como a proposta radical do JavaScript surgiu em 2018, fico curioso se a abordagem do Java influenciou em alguma medida
    • Sim, faz sentido ver assim: Joda influenciou o Moment.js, e isso depois se refletiu nas discussões do TC39
      O TC39 consulta precedentes de outras linguagens, mas chega a um consenso otimizado para JavaScript
      Acho que esta API é a implementação mais refinada já projetada por especialistas em JS ao longo de 9 anos
    • Sim, o JavaScript também herdou do Java uma versão ruim de Date
      Isso também pode ser visto neste tópico do HN
  • A frase “na era do Mocha, Ken Smith portou o código de Date do Java para C” é engraçada
    Porque o próprio util.Date do Java já era praticamente um port da API time.h do C
  • Ri ao ver que o Safari dá suporte parcial ao Temporal
    Agora parece que o Safari virou o sucessor espiritual do IE
    • O Safari é lento para adotar novos recursos, mas ainda assim continua implementando aos poucos
      O problema do IE não era lentidão, e sim o fato de ter parado enquanto estava em posição dominante
      Hoje o Chrome está no lugar do império, e Safari e Firefox são mais necessários do que nunca
      O verdadeiro problema é o aumento de sites feitos só para Chrome
    • Parece que mesmo em 2026 o Safari Mobile ainda não vai ter um seletor de data nativo
  • Eu gostaria que o Temporal tivesse um tipo interval 
    const D = new Temporal()
const t = new Interval({minutes:5})
const v = D.add(t)
    • Isso é Duration 
      const D = Temporal.PlainDate.from("2020-06-16");
const t = Temporal.Duration.from({ day: 1 });
const v = D.add(t) // 2020-06-17
      Veja a documentação da MDN
    • Isso mesmo, o nome é Duration
  • Obrigado à equipe por fazer viagem no tempo em velocidade 1x durante 9 anos para tornar isso possível