Las zonas horarias y la base de datos IANA

Un identificador de zona horaria como America/New_York o Asia/Shanghai no es una etiqueta de visualización: es el nombre de un conjunto completo de reglas. Registra, para una región, todos los desfases respecto al UTC que han estado en vigor y las fechas exactas en que cambiaron las reglas: cuándo empieza y termina el horario de verano, y cuándo se desplazó el propio desfase estándar subyacente. La ciudad del nombre no está ahí para mostrarse a un usuario. Ancla esa historia a un lugar cuyos relojes han seguido una secuencia coherente de leyes.

Por eso el software que se toma en serio el tiempo almacena un identificador de zona en lugar de un desfase pelado. «UTC-5» te dice dónde está el reloj en un instante; America/New_York te dice dónde estará en cualquier instante, pasado o futuro, aplicando la regla correcta para esa fecha. La base de datos que hay detrás de esos identificadores es la base de datos de zonas horarias de IANA, y entender lo que hace explica un número sorprendente de rarezas cotidianas.

El esquema de nombres Área/Ciudad

Los identificadores siguen un patrón Área/Ciudad: un área amplia —por lo general un continente como América, Europa, Asia o África— seguida de una ciudad representativa. America/New_York, Asia/Shanghai, Europe/London, Africa/Cairo. La ciudad se elige como ancla estable de las reglas, no por ser la mayor o la capital. Asia/Shanghai, por ejemplo, rige toda la China continental aunque el país abarque una anchura geográfica que cubriría de forma natural varias zonas, porque China funciona con una única hora oficial. El nombre marca la historia de las reglas, no una afirmación sobre la geografía.

Qué almacena realmente la base de datos tz

La base de datos tz —también llamada tzdata o zoneinfo, y mantenida bajo el paraguas de IANA— es un esfuerzo de décadas por registrar el tiempo civil con precisión. La fundó Arthur David Olson (razón por la que a veces se la sigue llamando la base de datos de Olson) y durante mucho tiempo la ha editado Paul Eggert. Su cobertura se remonta a 1970 con plena fidelidad, y a menudo antes, capturando los cambios históricos que hacen posible un cálculo de fechas honesto.

Como almacena historia en lugar de un único desfase actual, puede responder preguntas que el reloj de tu pared no puede. ¿Cuál era la hora local en una ciudad dada en una fecha concreta hace veinte años, antes de que ese país aboliera el horario de verano o moviera su desfase estándar? La base de datos lo sabe, porque registró la regla que estaba en vigor entonces en lugar de proyectar hacia atrás la regla de hoy.

Las abreviaturas son ambiguas; los desfases no son zonas

Dos hábitos causan la mayor parte de la confusión del mundo real, y la base de datos tz está diseñada para sortear ambos.

• Las abreviaturas chocan. «CST» no es una sola cosa. Es la hora estándar central de EE. UU. (UTC-6), la hora estándar de China (UTC+8) y la hora estándar de Cuba (UTC-5), entre otras. Un correo que dice «3 PM CST» es genuinamente ambiguo sin saber a qué país se refería el remitente. Un identificador completo como America/Chicago o Asia/Shanghai no lleva ninguna ambigüedad de ese tipo.
• Un desfase no es una zona. «UTC-5» describe un desfase en un momento. America/New_York es una zona que alterna entre UTC-5 en invierno y UTC-4 durante el horario de verano. Almacenar el desfase descarta la regla que decide cuál se aplica en una fecha futura; almacenar la zona la conserva.

La razón por la que los desfases y las zonas divergen es el horario de verano, y la mecánica de esos días de transición de 23 y 25 horas se trata en la guía complementaria sobre el horario de verano y el cálculo de fechas.

Las zonas cambian, y las actualizaciones salen varias veces al año

La base de datos no está congelada. Los países cambian de opinión: abolen el horario de verano, desplazan un desfase estándar, o dividen y fusionan zonas. Cuando lo hacen, sale una nueva versión de tzdata —esto ocurre varias veces al año, sin calendario fijo, impulsado por cuando un gobierno anuncia un cambio—. Las zonas también se renombran o fusionan con el tiempo a medida que reglas antes distintas convergen, y los nombres antiguos se conservan como alias para que los datos existentes sigan resolviéndose. Mantener la base de datos al día es lo que permite que una entrada de calendario hecha hoy siga siendo correcta después de que un país cambie sus reglas el año que viene.

Por qué AskTheDate pone la zona en la URL

AskTheDate incrusta una zona IANA en cada URL —una de 72 zonas seleccionadas— porque la misma pregunta de hora de reloj tiene genuinamente respuestas distintas en zonas distintas. Pregunta «¿qué día es?» cerca de la medianoche y la respuesta honesta depende por completo de dónde estés: puede ser ya mañana en Asia/Shanghai mientras sigue siendo hoy en America/New_York. Cocer la zona dentro de la dirección hace cada respuesta inequívoca, compartible y reproducible: el propio enlace registra contra qué reloj se calculó la respuesta, así que se lee igual para quien lo abra.

Puedes ver la divergencia directamente. La página de la hora de Nueva York y la página de la hora de Shanghái, durante buena parte de cada día, no coincidirán en la fecha del calendario: no es un fallo, sino la razón misma de que existan las zonas.

Pruébalo

Abre el conversor de zonas horarias de Nueva York y convierte una hora de Nueva York de última hora de la tarde a Asia/Shanghai. Mira cómo la fecha pasa al día siguiente: la demostración de un vistazo más clara de por qué lo que vale la pena almacenar es una zona, no un desfase.