El recorrido de 9 años que resolvió el problema del tiempo en JavaScript: Temporal

(bloomberg.github.io)

13 puntos por GN⁺ 2026-03-12 | 7 comentarios | Compartir por WhatsApp

La nueva API estándar Temporal, que reemplaza de raíz las limitaciones del objeto Date en JavaScript, llegó a ECMAScript Stage 4 tras 9 años de desarrollo
Temporal ofrece tipos inmutables, soporte explícito de zona horaria y calendario y precisión de nanosegundos, eliminando la ambigüedad y los errores de Date
Diversas organizaciones como Bloomberg, Igalia, Microsoft, Google y Mozilla colaboraron en el diseño e implementación de la especificación, y lograron una cooperación entre múltiples motores con la biblioteca compartida en Rust temporal_rs
Temporal brinda soporte preciso para operaciones temporales y calendarios internacionalizados mediante tipos detallados como ZonedDateTime, Instant, PlainDate/Time y Duration
Este estándar, que resuelve problemas acumulados durante 30 años, es valorado como un caso de éxito de colaboración e innovación abierta en el ecosistema de JavaScript

Los problemas del manejo del tiempo en JavaScript y la aparición de Temporal

El objeto Date existente fue una adaptación directa del Date de Java de 1995, y durante décadas ha sido fuente de bugs por problemas como mutabilidad, cálculos inconsistentes de meses y parsing ambiguo
- Ejemplo: errores al calcular fin de mes al usar setMonth, y resultados distintos entre navegadores al parsear cadenas similares a ISO
A medida que las aplicaciones web se volvieron más complejas desde la década de 2010, las limitaciones de Date se hicieron más graves
Los desarrolladores intentaron compensar estos problemas con bibliotecas externas como Moment.js, pero eso trajo mayor tamaño de bundle y carga de mantenimiento
En 2017, Maggie Johnson-Pint presentó la propuesta de Temporal ante TC39, iniciando así la discusión para su estandarización

Colaboración entre TC39 y la industria

Temporal comenzó en Stage 1 en 2018 y, tras 9 años, llegó a Stage 4 (estandarización)
Bloomberg participó activamente para resolver problemas de zona horaria y precisión en entornos JavaScript a gran escala
- Requisitos: zonas horarias personalizadas, precisión histórica de zonas horarias basada en IANA y precisión de nanosegundos
Se trabajó en el diseño e implementación de la especificación en colaboración con Igalia, Microsoft, Google y Mozilla
Varios ingenieros participaron como champions, entre ellos Philipp Dunkel, Ujjwal Sharma, Philip Chimento, Shane Carr y Justin Grant

Tipos y funciones principales de Temporal

Temporal.ZonedDateTime: representación inmutable de una fecha y hora que incluye zona horaria, calendario y ajuste de DST de forma explícita
- Ejemplo: si 01:30 no existe durante una transición de DST en Londres, se ajusta automáticamente a 02:30
Temporal.Instant: representación de un instante absoluto sin zona horaria ni calendario, con precisión de nanosegundos
- Permite convertir el mismo instante a múltiples zonas horarias
PlainDate / PlainTime / PlainDateTime / PlainYearMonth / PlainMonthDay: tipos de “reloj de pared” sin zona horaria
- Son adecuados para mostrar o calcular fechas y horas simples
Temporal.Duration: representa intervalos de tiempo y permite convertir entre distintas unidades (total({ unit: "second" }))
Soporte de calendario: realiza correctamente operaciones con calendarios no gregorianos, como el hebreo

Implementación y proceso de estandarización

Temporal es la adición más grande a la especificación en la historia de ECMAScript, con alrededor de 4,500 casos de prueba
Se desarrolló la implementación compartida en Rust temporal_rs, que motores como V8 y Boa usan en conjunto
- Ventajas: menor barrera de entrada, mantenimiento a largo plazo más sencillo y mejor calidad del código
Durante 2024 y 2025, temporal_rs alcanzó un 100% de pruebas aprobadas y fue considerado un caso exitoso de colaboración entre múltiples motores

Estado de soporte y retos futuros

Temporal ya tiene soporte en Firefox 139, Chrome/Edge 144 y TypeScript 6.0 Beta
- Safari está en la etapa de technical preview, y Node.js 26 está previsto
El siguiente reto es la integración con las Web APIs
- Ejemplo: soporte para tipos Temporal en elementos de formulario como <input type="date">
- También se estudia la posibilidad de reemplazar DOMHighResTimeStamp (con ejemplo de uso de Temporal.Now.instant())

Resultados de la colaboración y la innovación abierta

Temporal es un estándar completado mediante 9 años de colaboración entre múltiples organizaciones, en los que participaron
- actores diversos como Microsoft, Google, Mozilla, Bloomberg, Igalia y Boa
temporal_rs es un caso exitoso del modelo de infraestructura compartida, y
- demuestra reducción de costos por implementaciones duplicadas, mayor consistencia y aceleración de la innovación
Temporal es valorado no solo como una mejora de API, sino como una prueba de colaboración con la que la comunidad de JavaScript resolvió deuda técnica de largo plazo
Después de 30 años, JavaScript finalmente cuenta con una API moderna de fecha y hora

7 comentarios

jeeeyul 2026-03-12

La complejidad del cálculo del tiempo se debe mucho más que a un problema de formatos a la filosofía humana, la precisión de la astronomía y la cultura. Hacer cálculos es fácil incluso solo con long. Históricamente, en las líneas de tiempo hay muchos intervalos peculiares donde 1 + 1 no es 2, y gran parte de eso proviene de calendarios, casi como el I Ching, que cambian según la posición, como el ángulo del sol y la superficie terrestre. En esos casos, el calendario lunisolar coreano ni siquiera ha sido tema de discusión.

Y eso lo determina el Instituto Coreano de Investigación en Astronomía.

tsboard 2026-03-12

¡Por fin! ¡Qué alegría!!

shakespeares 2026-03-12

¡Por fin!!

roxie 2026-03-12

¿ZonedDateTime...? ¡No me digas que tú también..!

sea715 2026-03-12

Por fin

click 2026-03-12

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

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

Así ha sido el flujo, entonces.

GN⁺ 2026-03-12

Comentarios de Hacker News

Me encanta que Temporal obligue a manejar bien la complejidad del tiempo
La distinción entre un instante (instant) y un datetime basado en calendario evita casi por completo los errores comunes que pasaban con Date
Es un poco verboso, pero sigue siendo mucho mejor que recibir una llamada a las 3 a. m. para arreglar un bug de DST
- Técnicamente, diría que tener que arreglar un bug de DST a las 3 a. m. casi no pasaría fuera de los domingos
Yo también sufrí casi 10 años con el problema de parsear fechas ISO8601 en Python
Fue un issue que empezó en 2012 y al final terminó llegando a la librería estándar como solución
La discusión relacionada puede verse en este hilo de Google Groups
- De verdad, muchas gracias. Parsear fechas de otra forma que no sea fromisoformat ahora ya se siente demasiado poco intuitivo
  Antes usaba ciso8601, pero desde que entró al estándar todo es mucho más simple y estable
Es especialmente impresionante que Firefox haya podido implementar Temporal desde la etapa de especificación gracias a André Bargull (Anba),
y que en realidad él haya implementado todo por su cuenta como voluntario
Temporal es un gran avance, pero aun así la API no me convence
Como comparto código entre cliente y servidor, intento separar estrictamente los datos y la lógica
Quiero mantener todos los datos como JSON puro para facilitar serialización y deserialización, pero los objetos de Temporal son instancias de clase con propiedades de función, y eso me resulta incómodo
Creo que un enfoque como date-fns, donde se aplican funciones puras a objetos de solo datos, es mejor
- Ese es un diseño intencional. Los tipos de Temporal se pueden serializar, pero no se restauran automáticamente con JSON.parse
  El desarrollador tiene que reconstruir manualmente el objeto correcto a partir de la cadena ISO
  Si se automatiza, existe el riesgo de terminar manejando tipos incorrectos
  El ejemplo de reviver para Temporal.Instant en la documentación puede servir de referencia
- A mí también me pasa mucho lo mismo. Que JSON.parse/stringify haga desaparecer el prototipo es un problema común
  Pero creo que la elección del equipo de Temporal es la correcta. En la lógica de fecha y hora, la seguridad de tipos importa más que un enfoque simple de datos+funciones
  Si encapsulas las operaciones en el objeto, evitas que un PlainDate se trate por error como un ZonedDateTime
  En cosas como tRPC, basta con agregar una capa delgada en los bordes que convierta con Temporal.from() y toString()
  Es un poco más incómodo, pero me parece mejor que renunciar a la seguridad de tipos
- En realidad, las instancias de Date de JavaScript tienen el mismo problema
  Date.toJSON existe, pero al parsear JSON igual tienes que volver a convertir la cadena en Date
  Temporal es igual, y date-fns al final también trabaja con instancias nativas de Date
- Todos los objetos de Temporal pueden serializarse y deserializarse fácilmente con .toString() y Temporal.from()
- Me parece excesivo cambiar JSON.parse para que cree objetos Temporal automáticamente
  Igual que con Date,
```
serialize: instant.toJSON()
deserialize: Temporal.Instant.from(jsonDate)
```
  lo correcto es manejarlo explícitamente de esa manera
Me alegra muchísimo que Temporal haya sido aprobado
Felicidades a todos los champions que trabajaron en esto durante tanto tiempo
Disfruté mucho trabajar en temporal_rs en los últimos años
Habría sido interesante mencionar también el recorrido de mejora de la API de tiempo en Java (Joda-Time → JSR 310 → Java 8)
Como la propuesta radical de JavaScript apareció en 2018, me da curiosidad si el enfoque de Java influyó en alguna medida
- Sí, lo correcto es verlo como que Joda influyó en Moment.js, y eso luego se reflejó en las discusiones de TC39
  TC39 toma como referencia antecedentes de otros lenguajes, pero llega a consensos orientados a JavaScript
  Creo que esta API es la implementación más pulida que expertos de JS han diseñado a lo largo de 9 años
- Exacto, JavaScript también heredó de Java una mala versión de Date
  También se puede ver algo sobre eso en este hilo de HN
Me dio risa la frase “en la época de Mocha, Ken Smith porteó a C el código de Date de Java”
porque util.Date de Java en realidad ya era casi un port del API time.h de C
Me dio risa ver que Safari tiene soporte parcial para Temporal
Ahora parece que Safari se convirtió en el heredero espiritual de IE
- Safari es lento para adoptar funciones nuevas, pero aun así las sigue implementando de manera constante
  El problema de IE no era la lentitud, sino que se quedó estancado desde una posición dominante
  Ahora Chrome está en el lugar del imperio, y de hecho Safari y Firefox son más necesarios
  El verdadero problema es que cada vez haya más sitios hechos solo para Chrome
- Siento que ni siquiera en 2026 Mobile Safari va a tener un selector de fecha nativo

Ojalá Temporal tuviera un tipo interval

const D = new Temporal()
const t = new Interval({minutes:5})
const v = D.add(t)

Eso es Duration

const D = Temporal.PlainDate.from("2020-06-16");
const t = Temporal.Duration.from({ day: 1 });
const v = D.add(t) // 2020-06-17

Ver documentación de MDN

Sí, eso se llama Duration

Gracias al equipo por hacer viaje en el tiempo a velocidad 1x durante 9 años para sacar esto adelante