Carlos Vega
27 años esperando: de java.util.Date a Temporal
El 13 de enero de 2026, Chrome 144 shipped Temporal, la API que finalmente reemplaza a Date después de 27 años. Después de 9 años de desarrollo en TC39 (desde 2017), 105 contributores core, y 3.7k stars en GitHub, JavaScript tiene fechas que funcionan.
Diciembre de 1995. Brendan Eich tiene 10 días para crear JavaScript. Necesita manejar fechas. ¿La solución más rápida? Copiar java.util.Date de Java. Tomó el código de Java, lo adaptó en tiempo récord, y lo lanzó sin mirar atrás.
Dos años después, en 1997, Java deprecó java.util.Date porque era un desastre. Pero JavaScript quedó atrapado: la web no permite romper compatibilidad. Si Chrome cambiara Date hoy, 3.98 mil millones de sitios web podrían romperse.
Ahora viene la parte incómoda: tres cosas que Google no menciona en su anuncio oficial.
El problema: solo el 49.47% puede usar Temporal sin polyfills
¿Cuántos de tus usuarios tienen Temporal nativo en su browser?
Según Can I Use, Temporal cubre exactamente 49.47% de usuarios globales en febrero 2026.
¿Por qué tan bajo si Chrome tiene 70.5% de market share? Porque Chrome 144 shipped hace solo un mes. Millones de usuarios todavía usan Chrome 143, 142, 141. Firefox 139 (mayo 2025) fue el primer browser en implementar Temporal, pero Firefox solo tiene 3.12% de market share.
El problema real se llama Safari. iOS obliga a todos los browsers (Chrome iOS, Firefox iOS, Edge iOS) a usar el motor WebKit de Safari. Y Safari no tiene Temporal en producción. Solo en Technical Preview con un flag experimental llamado useTemporal.
Apple no ha comunicado cuándo shippeará Temporal en Safari stable.
Históricamente, Safari retrasa features complejas 1-2 años después de Chrome. CSS Container Queries: Chrome marzo 2022, Safari septiembre 2023 (18 meses). Scroll-driven Animations: Chrome agosto 2023, Safari todavía sin soporte en 2026.
50.53% de tus usuarios no tienen Temporal nativo. Si quieres usarlo en producción cross-browser hoy, necesitas @js-temporal/polyfill. Peso del polyfill oficial: ~300KB. Eso es más pesado que moment.js (que Google te dice que elimines).
Qué ganas con Temporal (cuando funcione en todos lados)
Cuando Temporal finalmente tenga soporte universal, vas a poder hacer esto:
Inmutabilidad nativa. Date muta objetos, lo que genera bugs silenciosos:
// Date (mutable - PELIGRO)
const fecha = new Date('2026-02-12');
fecha.setMonth(3); // Mutó el objeto original
console.log(fecha); // Ahora es abril, no febrero
// Temporal (inmutable - SEGURO)
const fecha = Temporal.PlainDate.from('2026-02-12');
const abril = fecha.with({ month: 4 }); // Retorna nuevo objeto
console.log(fecha); // Sigue siendo febrero
Timezone-aware por defecto. Date mezcla local time con UTC, causando bugs de "off-by-one-hour" en DST:
// Date (naive - ignora DST)
const fecha = new Date('2026-03-08T02:30:00'); // Hora que no existe en DST
// JavaScript inventa una hora incorrecta
// Temporal (correcto)
const zoned = Temporal.ZonedDateTime.from({
timeZone: 'America/New_York',
year: 2026, month: 3, day: 8,
hour: 2, minute: 30
}); // Lanza error: hora ambigua por DST
Precisión de nanosegundos. Date usa milisegundos, Temporal.Instant usa nanosegundos (1000x mejor). Crítico para:
- Trading financiero de alta frecuencia
- Logs de sistemas distribuidos
- Timestamps de eventos en tiempo real
API específica por caso de uso. En lugar de un Date que hace todo mal, tienes:
Temporal.PlainDatepara calendarios (sin hora)Temporal.PlainTimepara horarios (sin fecha)Temporal.ZonedDateTimepara eventos con timezoneTemporal.Instantpara timestamps absolutosTemporal.Durationpara medir intervalos
La API tiene un costo oculto.
La polémica que nadie menciona: TC39 recortó funcionalidades clave
En junio 2024, en la reunión de TC39 en Helsinki, Philip Chimento y Justin Grant presentaron un "scope reduction" controversial: eliminar Temporal.Calendar y Temporal.TimeZone customizables.
¿La razón oficial? Bundle size en Android low-end y Apple Watch. Los implementadores (Google, Apple, Mozilla) reportaron que soportar calendarios y timezones customizables agregaba demasiado peso al motor de JavaScript.
¿A quién afecta esto? A empresas que necesitan:
- Calendarios fiscales custom (años fiscales que no coinciden con enero-diciembre)
- Calendarios lunares no-gregorianos para apps religiosas
- Timezones custom para zonas horarias que IANA no reconoce
La propuesta original de 2017 permitía que desarrolladores crearan sus propios calendarios y timezones. Esa funcionalidad murió en 2024. Los implementadores querían reducir complejidad.
Según el issue #2854 en GitHub, varios contributores protestaron: "Esto convierte Temporal en 90% de lo que prometimos, no 100%". Pero la decisión ya estaba tomada.
Resultado: Temporal soporta calendarios gregorianos, japoneses, islámicos, chinos, hebreos, indios, budistas — pero solo los que vienen built-in. Si tu empresa necesita un calendario fiscal custom, estás out of luck.
Safari te obliga a elegir: ¿polyfill de 300KB o esperar 2 años?
Aquí está tu decisión práctica en febrero 2026.
Puedes usar Temporal con polyfill: agregas @js-temporal/polyfill (~300KB), funciona en todos los browsers incluyendo Safari, pagas el costo de bundle size para el 50.53% sin soporte nativo, cubres iOS (54% del mercado móvil en EE.UU.).
O esperas a Safari: no agregas polyfill, solo usas Temporal en Chrome/Firefox, tu app rompe para la mitad de tus usuarios, timeline desconocido (Apple no comunica roadmap), riesgo de que Safari tarde hasta 2028 based on patrones históricos.
O sigues con date-fns: 49 millones de descargas semanales, ~80KB en bundles típicos (tree-shakeable), funciona cross-browser HOY sin polyfills, inmutable, funcional, API probada desde 2016.
Mi recomendación honesta después de analizar todo esto: si estás en producción enterprise y necesitas cross-browser support, date-fns sigue siendo la opción más segura en 2026. Temporal es el futuro, pero ese futuro está fragmentado.
Ojo con esto: si tu app es Chrome-only (apps internas de empresa, dashboards admin), Temporal ya es viable nativo. Pero si tienes usuarios de iOS, espera a que Can I Use muestre >80% coverage. Caso contrario, el polyfill de 300KB niega el beneficio de "eliminar moment.js".
¿Mi predicción? Safari shippeará Temporal en Safari 19 (septiembre 2026) o Safari 20 (marzo 2027). Recién ahí, cuando Can I Use pase 75%, la migración masiva de date-fns a Temporal empezará. Mientras tanto, conviven dos ecosistemas: el nativo (Chrome/Firefox early adopters) y el polyfillado (producción real cross-browser).
Brendan Eich tardó 10 días en crear Date en 1995. Java lo deprecó en 1997. JavaScript esperó 27 años para arreglarlo. Y ahora que Temporal llegó, Safari te hace esperar 1-2 años más. Así es la web platform en 2026.
