Qué es la base de datos de zonas horarias de IANA (y por qué importa)

Cuando tu portátil retrocede silenciosamente una hora un domingo por la mañana, o cuando una invitación de calendario de un colega en São Paulo llega exactamente en el momento que esperabas, fue lo mismo invisible lo que hizo el trabajo: un conjunto de datos mantenido de forma libre que casi todos los sistemas operativos, lenguajes de programación y servicios web tratan como la autoridad sobre la hora civil. Es la base de datos de zonas horarias de IANA — también llamada base de datos tz, tzdata o, históricamente, base de datos de Olson, en honor a Arthur David Olson, que empezó a mantenerla en los años ochenta.

Las zonas horarias parecen geografía, pero son política. Un gobierno puede decidir terminar el horario de verano antes de tiempo, cambiar su desfase estándar o saltarse un día entero — a veces con solo semanas de antelación. La base de datos tz es el reglamento común que absorbe esos cambios para que «¿qué hora es en Londres cuando son las 3 de la tarde en Nueva York?» tenga una única respuesta consistente en todas partes. Este artículo explica qué contiene realmente la base de datos, cómo viaja una actualización desde un decreto gubernamental hasta tu teléfono y por qué el tentador atajo de almacenar un desfase fijo como «UTC+1» es un error en ciernes.

Qué es realmente la base de datos

La base de datos tz es un conjunto de archivos de texto plano que describen las reglas de la hora local del reloj en todo el mundo — tanto ahora como tan atrás como los registros razonablemente lo permitan. No la ejecutas; el software la lee. Cualquiera puede descargarla, y los datos no llevan restricciones de licencia, lo que en parte explica por qué terminó en todas partes.

Cada región se identifica mediante un nombre de zona con la forma `Area/Location`: `America/New_York`, `Europe/London`, `Asia/Kolkata`, `Australia/Lord_Howe`. La ubicación suele ser una ciudad representativa, no un país, y eso es deliberado. Un solo país puede abarcar varios conjuntos de reglas, y los nombres de ciudad son mucho más estables a lo largo de las décadas que las fronteras o los nombres de país. La base de datos define unos cuantos cientos de estas zonas.

Para cada zona, los datos registran:

• El desfase base respecto a UTC — por ejemplo, `America/New_York` es UTC−5 en invierno (EST).
• Las reglas del horario de verano vigentes, incluyendo exactamente cuándo empiezan y terminan cada año.
• Las transiciones históricas — cada cambio pasado en el desfase o la regla de DST de esa zona.
• Las abreviaturas que se aplicaron en cada período, como EST, EDT, CET o IST.

Esa dimensión histórica es lo que separa a tzdata de una simple tabla de desfases. No solo sabe que Nueva York es UTC−5 hoy. Sabe que Estados Unidos adelantó la fecha de inicio de su DST a partir de 2007, y aplica la regla correcta para cualquier fecha que consultes. Por eso un buen conversor puede decirte el desfase para una fecha de 1995 con la misma seguridad que para el próximo martes.

Zonas, enlaces y las confusas entradas «Etc»

La base de datos también define enlaces — alias que apuntan un nombre hacia otro para que los cambios de nombre no rompan los sistemas existentes. Cuando la zona de la India se asentó en `Asia/Kolkata`, el antiguo `Asia/Calcutta` se conservó como un enlace hacia ella. Ambos siguen resolviéndose en UTC+5:30.

También hay zonas `Etc/` para desfases fijos, incluyendo `Etc/UTC` y la famosamente invertida `Etc/GMT+5`. Esa es UTC−5, no UTC+5: los nombres `Etc/GMT±` invierten el signo por una vieja convención de POSIX. Estas zonas de desfase fijo existen para necesidades técnicas muy concretas. Para cualquier lugar donde vivan personas reales, quieres una zona geográfica — porque solo una zona geográfica conoce el horario de verano y los futuros cambios de reglas. La siguiente sección explica por qué eso importa.

Por qué las reglas de las zonas horarias cambian tan a menudo

La gente asume que las zonas horarias están fijadas. No lo están. La base de datos tz se actualiza varias veces en un año típico, a veces más. Las versiones se identifican por año y una letra — `2023a`, `2023b`, `2024a` — y cada una agrupa todos los cambios de reglas y correcciones que se han acumulado desde la anterior.

Los cambios provienen de un puñado de fuentes recurrentes:

• Gobiernos que ajustan la política de DST. Un país empieza a observar el horario de verano, deja de hacerlo o cambia las fechas de transición. La Unión Europea lleva años debatiendo la abolición del cambio estacional de hora, y varios estados de EE. UU. han aprobado leyes que buscan un DST permanente que aguardan la aprobación federal.
• Cambios de desfase directos. Ocasionalmente un territorio adopta una hora estándar completamente distinta. El caso clásico: a finales de 2011, Samoa se saltó el 30 de diciembre por completo, saltando al otro lado de la Línea Internacional de Cambio de Fecha para alinear su semana laboral con Australia y Nueva Zelanda en lugar de con la Costa Oeste de EE. UU.
• Anuncios con poca antelación. Esta es la parte difícil. A veces un gobierno anuncia un cambio semanas — o días — antes de que entre en vigor. Los mantenedores y los proveedores posteriores compiten entonces por publicar y distribuir una actualización antes de que llegue la fecha.
• Correcciones históricas. Los investigadores descubren viejos estatutos, archivos de periódicos u horarios de ferrocarril que precisan cuál *era* el desfase de una zona hace décadas, y esas correcciones también se incorporan.

La conclusión contundente: la regla de un lugar solo se conoce hasta la próxima decisión gubernamental. Cualquier sistema que asuma que las reglas de hoy son permanentes acabará por equivocarse.

Cómo llega una actualización a tu teléfono

La base de datos la mantiene una comunidad de voluntarios que se coordinan en una lista de correo pública, con IANA (la Autoridad de Números Asignados de Internet) actuando como hogar oficial y punto de distribución. Un cambio normalmente viaja así:

1. Alguien lo reporta en la lista de correo de tz, normalmente citando un boletín oficial del gobierno, un anuncio oficial o una investigación con fuentes primarias. 2. Los mantenedores lo verifican y lo debaten, y luego confirman la edición en el archivo de datos pertinente. 3. IANA publica una nueva versión con una etiqueta de versión como `2024a`. 4. Los consumidores posteriores la incorporan — distribuciones de Linux, macOS, entornos de ejecución de lenguajes y grandes plataformas. (Windows mantiene su propio formato de zona horaria y lo mapea a los nombres de IANA). 5. Tu dispositivo la recibe a través de una actualización del sistema operativo, una actualización de aplicación o, en los servidores, un paquete como `tzdata`.

Esta canalización es también donde nacen los errores del mundo real. La base de datos puede estar perfectamente al día mientras un dispositivo concreto no lo está. Un portátil que se perdió la actualización sigue aplicando la regla antigua, y el reloj queda mal el día de la transición. El desfase entre «la regla cambió» y «todos los dispositivos lo saben» es la mayor fuente individual de errores de zona horaria que encontrarás en la práctica.

Por qué los desfases codificados se quedan obsoletos

Aquí está el error que todo el sistema existe para evitar. Un desarrollador decide almacenar la zona horaria de un usuario como un simple número — `+1` — porque parece eficiente. Está roto de tres maneras a la vez.

• Ignora el DST. `Europe/Paris` es UTC+1 en invierno y UTC+2 en verano. Un `+1` almacenado solo es correcto durante parte del año, y cada primavera y otoño el cálculo se desvía una hora.
• No puede representar la transición en sí. La mañana en que un reloj se adelanta, una hora local no existe; la mañana en que se atrasa, una hora local ocurre dos veces. Un desfase pelado no tiene forma de decir «las 02:30 ocurrieron dos veces». Una zona con nombre, aplicada mediante una lógica de fechas correcta, sí puede.
• Congela una regla que va a cambiar. Si una región abole el DST el año que viene, la base de datos tz publica una actualización y todo sistema conforme se adapta automáticamente. Un `+1` codificado sigue aplicando para siempre la política del año pasado, produciendo silenciosamente horas incorrectas.

Un ejemplo resuelto, con desfases verificados

Programa una llamada recurrente para todos los lunes a las 09:00 en Berlín, a la que se une alguien en Chicago. Observa cómo se mueve la diferencia a lo largo del año:

• Mediados de enero: Berlín está en CET (UTC+1), Chicago está en CST (UTC−6). La diferencia es de 7 horas, así que la llamada es a las 02:00 en Chicago.
• Mediados de julio: ambos han pasado al horario de verano — Berlín CEST (UTC+2), Chicago CDT (UTC−5). Siguen siendo 7 horas, así que sigue siendo a las 02:00 en Chicago.
• Mediados de marzo: los dos países *no* cambian el mismo día. En 2025 EE. UU. se adelantó el 9 de marzo, pero la UE no lo hizo hasta el 30 de marzo. Durante esas tres semanas Chicago ya estaba en CDT (UTC−5) mientras Berlín seguía en CET (UTC+1) — una diferencia de solo 6 horas, lo que hace la llamada a las 03:00 en Chicago.

Una herramienta que almacenara «Berlín = +1, Chicago = −6» se equivocaría por una hora en julio *y* durante las semanas de solapamiento de marzo. Solo un sistema que resuelve las zonas con nombre contra la *fecha específica* acierta cada semana. Así es exactamente como funcionan el planificador de reuniones y el conversor de Timezio: preguntan qué lugar quieres decir y luego aplican las reglas vigentes para la fecha en cuestión en lugar de un número congelado.

Una lista de comprobación práctica

Nunca necesitas abrir un archivo de tzdata para beneficiarte de cómo funciona. Cinco hábitos llevan ese valor al uso cotidiano:

• Almacena y comparte lugares, no desfases. «Estoy en `America/Los_Angeles`» sobrevive al DST y a los cambios de política. «Estoy en UTC−8» no.
• Mantén tus sistemas actualizados. La razón más común de que un reloj esté mal un fin de semana de transición es un dispositivo que se perdió la última versión de `tzdata`. Las actualizaciones del sistema operativo y de las aplicaciones son la forma en que la corrección llega a ti.
• Desconfía de cualquier herramienta que muestre un único desfase fijo para una ciudad. Si no puede tener en cuenta la fecha, no puede tener en cuenta el DST.
• Vuelve a comprobar los eventos transfronterizos en los fines de semana de cambio de hora y después de cualquier anuncio gubernamental. Es precisamente cuando el desfase entre la regla y la actualización golpea con más fuerza.
• Trata cada respuesta como provisional. La conversión correcta de hoy solo es correcta hasta el próximo decreto.

La base de datos de zonas horarias de IANA es una de las piezas más silenciosas de infraestructura compartida en línea — un conjunto de archivos de texto mantenido por voluntarios en el que el mundo digital se apoya para la hora civil. Funciona porque trata a las zonas horarias por lo que realmente son: un objetivo móvil moldeado por la política, no una cuadrícula fija dibujada en un mapa. Cada conversión precisa de la que dependes, incluida la de Timezio, depende de que alguien, en algún lugar, haya anotado la última regla y la haya publicado antes de que cambiaran los relojes.