Formato de fechas y portabilidad de zonas horarias

El formato fiable de fechas en el navegador empieza por un modelo claro. Guarda un instante cuando el evento es un punto de la línea temporal, una fecha de calendario cuando solo representa un día, y elige una política de zona horaria antes de llamar a Intl.DateTimeFormat. La configuración regional controla el idioma y el orden, pero no decide qué zona usa una cita. Separar estas decisiones evita fechas desplazadas, sorpresas de horario de verano y significados distintos entre navegadores.

ECMA-402 define los servicios de internacionalización. MDN documenta Intl.DateTimeFormat y W3C explica por qué fecha y zona son datos diferentes. Estas fuentes permiten una capa de presentación portable, pero no prometen idéntica puntuación o abreviatura en todos los entornos.

Define el valor antes de formatearlo

Un instante como 2026-01-01T01:30:00Z identifica el mismo momento en cualquier lugar. El sufijo Z indica UTC. Fechas de eventos, auditorías, pagos y entregas de mensajes suelen necesitar un instante porque cada lector puede estar en otra zona.

Una fecha de calendario es distinta. Un cumpleaños, una entrada de hotel o un periodo de facturación puede significar el día nombrado por el negocio, no la medianoche de un instante. Si se convierte a UTC y luego a la zona del lector, puede terminar en el día anterior o siguiente. Conserva una fecha sin hora cuando el dominio no define una hora.

La hora local de una sede necesita sus campos locales y una zona IANA. “09:00 en Berlín” no es “09:00 en la zona actual del lector”. El producto debe indicar si manda la zona del lugar, la elegida por el participante o una zona fija de informes. No pases cadenas ambiguas al analizador de JavaScript: define el contrato de entrada y conserva el valor estructurado.

Elige la política de zona explícitamente

Pasa timeZone: 'UTC' para un informe estable o timeZone: 'America/New_York' para la hora civil de esa región. Omitir la opción suele usar la zona predeterminada del entorno; puede servir para un reloj personal, pero no para un informe que promete una zona fija. La fuente de la zona debe ser una elección visible del usuario, la sede del evento o una regla de la organización. Una preferencia del navegador solo es un valor inicial, nunca prueba de residencia o identidad.

Muestra el nombre, el desfase o una etiqueta de zona cuando comparar horarios importa. Guarda un identificador IANA para eventos recurrentes; un desfase fijo no describe un cambio futuro de horario de verano. Usa el valor que corresponda al dominio y documenta cualquier conversión.

Usa ECMA-402 sin fijar la puntuación

El formateador recibe idioma, opciones y zona. La aplicación decide qué campos expresan significado; el navegador decide orden, dígitos y puntuación. Idioma y zona son elecciones independientes: una interfaz en español puede mostrar una reunión en Toronto, y una interfaz en francés puede mostrar un informe UTC. formatToParts() ayuda a crear una presentación semántica, pero no asumas el mismo orden en todos los idiomas.

No compares una cadena exacta entre versiones de navegador. Los datos regionales pueden cambiar. Comprueba el valor, las opciones, el día y la hora que entiende el usuario. Mantén los datos de máquina separados del texto humano: bases de datos, API, registros y firmas requieren contratos estables, y un texto localizado no debe volver a analizarse como una marca temporal.

Trata horario de verano y calendarios como casos normales

Durante un cambio de horario puede existir una hora dos veces o no existir. Un sistema de citas debe documentar cómo resuelve ambos casos antes de guardar. Intl.DateTimeFormat presenta un instante ya resuelto; no define esa regla. Prueba zonas IANA reales antes y después de las transiciones, citas recurrentes y lectores en zonas distintas.

Los calendarios y los años bisiestos requieren la misma separación. Añadir 24 horas a un instante no siempre significa avanzar un día civil. Decide si una recurrencia sigue duración transcurrida o aritmética de calendario y formatea después de aplicar esa regla.

Conserva una alternativa portable

Detecta las opciones que realmente utilizas. Si no están disponibles, usa una configuración sencilla, una vista generada por el servidor o una fecha estructurada con etiqueta UTC. La alternativa debe conservar valor y contexto; nunca cambies silenciosamente la hora de la sede por la del lector ni elimines la zona de un plazo.

Resuelve etiquetas regionales solicitadas contra una lista de idiomas admitidos. Una variante regional ausente puede volver al idioma base sin cambiar la política de zona. Las actualizaciones del sistema pueden cambiar reglas futuras: guarda el instante original y el identificador de zona. Servidor y navegador deben compartir el valor estructurado y la zona declarada para evitar un primer render UTC seguido de un salto local.

Haz la vista accesible

Etiqueta el propósito de una fecha: vencimiento, salida, renovación o medición. Incluye contexto de zona cuando sea posible la confusión. Usa etiquetas semánticas, texto ampliable y diseños que permitan nombres largos. Comprueba lectores de pantalla y escritura de derecha a izquierda. Al cambiar idioma o zona, conserva el formulario y la identidad del evento, y explica si solo cambia la presentación.

Los errores deben decir si se espera una fecha de calendario, un instante con desfase o una hora local con zona. Incluye un ejemplo en el idioma activo. “Fecha no válida” no ayuda a resolver una hora ambigua durante una transición.

Prueba tareas reales

Usa un instante, una fecha sin hora, una cita de sede y una recurrencia. Con 2026-01-01T01:30:00Z, UTC muestra el 1 de enero de 2026 a la 01:30 y America/New_York el 31 de diciembre de 2025 a las 20:30. Ambos resultados deben representar el mismo instante y mostrar su zona; los espacios y signos pueden variar. Una fecha de calendario como 2026-01-01 debe seguir siendo 1 de enero en cualquier zona.

Al investigar un problema, registra versión de la aplicación, navegador, datos de zona del sistema, idioma, entrada y política elegida. Es suficiente para reproducir el resultado visible sin crear un inventario de características del navegador. No conviertas preferencias de idioma o zona en una señal de identidad.

La portabilidad de fechas es un contrato: los valores estructurados fijan el significado, una política explícita fija el contexto y ECMA-402 produce la presentación localizada. Así, una actualización puede cambiar la puntuación sin cambiar el evento y el usuario puede cambiar idioma o zona sin corromper los datos.

Nombra los campos como instante, fechaCalendario, horaLocal y zonaHoraria para que una revisión pueda detectar conversiones accidentales.

Un mensaje enviado por correo o notificación debe incluir fecha, hora y zona cuando existe un plazo, porque puede leerse lejos de la interfaz original.

Las migraciones de cadenas antiguas merecen una revisión del dominio: convertir una fecha sin hora en UTC puede cambiar el día visible.

Los registros operativos pueden usar UTC de forma consistente y ofrecer una zona separada para los paneles de cada lector.

Las pruebas deben incluir una fecha cercana al cambio de mes, otra cercana al cambio de año y una zona con reglas históricas.

El diseño debe reservar espacio para nombres de meses largos y permitir que una etiqueta de zona se divida en varias líneas.

Un selector de zona debe mostrar el nombre que la persona reconoce, no solo un número de desfase ambiguo.

La copia exportada debe conservar el contexto de zona y el tipo de valor para que siga siendo comprensible fuera de la aplicación.

Al cambiar de idioma, el formato de números y fechas puede cambiar sin convertir monedas ni modificar el instante guardado.

El servidor debe enviar el valor estructurado antes de que el navegador el presente, evitando dos políticas ocultas durante la hidratación.

Una función de calendario recurrente necesita una regla documentada para los días que no existen después de un ajuste de mes.

Las horas repetidas deben distinguirse con el instante o con una indicación de desplazamiento antes de confirmar una cita.

La información de soporte debe limitarse a los datos necesarios para reproducir el resultado, no a un perfil general del navegador.

Una prueba de accesibilidad debe leer en voz alta la fecha completa y su zona, incluso si la vista visual utiliza una forma abreviada.

Cuando un formato no está disponible, el mensaje de reserva debe conservar la fecha y explicar el contexto en un idioma compatible.

Las abreviaturas de zona pueden cambiar entre versiones; el identificador IANA y el instante son las referencias estables.

El producto debe decidir si el usuario puede editar una fecha local o únicamente seleccionar un instante ya confirmado.

Estas decisiones hacen que una diferencia de tipografía sea una variación inocua y no una pérdida de significado.

Fuentes

• ECMA-402
• MDN: Intl.DateTimeFormat
• W3C Internacionalización: zonas horarias
• WHATWG HTML: Web application APIs

Consulta la guía de localización por idioma del navegador y la guía de datos regionales de Intl. Ninguna sustituye la decisión explícita sobre instantes, fechas de calendario y citas locales.