Lo que realmente es la Base de Datos de Zonas Horarias de IANA
Si alguna vez has trabajado con fechas y horas en software, has dependido de la Base de Datos de Zonas Horarias de IANA, lo supieras o no. Se conoce por varios nombres — tz database, tzdata, la base de datos Olson, o zoneinfo — pero todos se refieren a lo mismo: un catálogo colaborativo y disponible gratuitamente de las zonas horarias del mundo y las reglas que las rigen.
La palabra "catálogo" se queda corta. La base de datos no solo enumera qué regiones están en qué offset UTC. Registra la historia completa de la medición del tiempo civil para cada región — cada cambio de offset, cada transición de horario de verano, cada cambio de reloj en tiempos de guerra, y cada regla futura programada — remontándose, en muchos casos, a mediados del siglo XIX, cuando el tiempo medio local dio paso a zonas estandarizadas. Cuando tu aplicación de calendario muestra correctamente que una reunión en 1985 ocurrió una hora diferente de la misma hora de reloj actual, eso es la base de datos tz en acción.
Es basada en texto, legible por humanos y pequeña. La forma binaria compilada que viene en tu computadora tiene solo unos pocos megabytes. Sin embargo, codifica uno de los conjuntos de datos más silenciosamente complicados en la informática.
Una breve historia
El proyecto comenzó en los años 80 bajo Arthur David Olson, quien ensambló la primera versión y la alojó en servidores de los Institutos Nacionales de Salud de EE.UU. Durante décadas se mantuvo principalmente a través de un esfuerzo voluntario coordinado mediante una lista de correo pública, por lo que el nombre antiguo "base de datos Olson" todavía aparece en la documentación.
Paul Eggert asumió como editor principal y sigue siendo el coordinador de larga data del proyecto. Su compilación del documento adjunto theory.html y el meticuloso historial de commits han hecho de la base de datos tanto una referencia histórica como técnica.
En 2011, después de una breve pero alarmante disputa legal sobre los datos históricos, la administración pasó a la Autoridad de Números Asignados de Internet (IANA), el mismo organismo que coordina otros recursos centrales de Internet. IANA ahora publica versiones oficiales, por lo que "base de datos de zonas horarias de IANA" se ha convertido en el nombre canónico. El trabajo aún lo realiza la misma comunidad de colaboradores; IANA proporciona un hogar institucional y un punto de distribución estable.
La convención de nombres: Área/Ubicación
Una de las características más distintivas de la base de datos es cómo nombra las zonas. En lugar de nombres de países u offsets brutos, utiliza un formato Área/Ubicación, casi siempre anclado a una ciudad representativa:
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
El "Área" suele ser un continente u océano (America, Europe, Asia, Pacific), y la "Ubicación" es una ciudad conocida dentro de la zona. Esta elección parece peculiar hasta que se entiende el razonamiento detrás de ella.
Las ciudades son estables; las fronteras políticas y los offsets no lo son. Los países se dividen, fusionan, cambian de nombre y modifican sus relojes. Una ciudad, en cambio, es un punto geográfico fijo con un historial continuo de medición del tiempo. Nombrar una zona America/New_York en lugar de "Hora del Este de EE.UU." o "UTC-5" significa que el identificador sigue siendo válido incluso cuando las reglas asociadas evolucionan.
La base de datos también evita deliberadamente los nombres de países para evitar disputas políticas y porque un solo país suele contener varias zonas — Estados Unidos tiene más de una docena. Elige la ciudad más poblada o históricamente significativa en cada zona distinta como una etiqueta neutral. Cuando dos regiones han compartido un historial de reloj idéntico desde 1970, comparten una zona; en el momento en que sus historias divergen, reciben entradas separadas.
Por qué los offsets brutos no son suficientes
Un instinto común de principiante es almacenar una hora como "UTC+5:30" y darlo por terminado. Esto funciona para un instante único, pero se desmorona en el momento en que necesitas razonar sobre eventos futuros o recurrentes, porque los offsets no son propiedades estáticas de un lugar. Son el resultado de reglas que los gobiernos cambian constantemente y a menudo abruptamente.
Considera algunos ejemplos reales que la base de datos ha tenido que absorber:
- Samoa omitió el 30 de diciembre de 2011 por completo. Para alinear su día laboral con Australia y Nueva Zelanda en lugar de con Estados Unidos, Samoa saltó la Línea Internacional de Cambio de Fecha, pasando de UTC-11 a UTC+13. Para cualquiera en las islas, ese viernes simplemente no existió.
- Los países abolen, adoptan o reprograman el horario de verano con poco aviso. La Unión Europea ha debatido poner fin al horario de verano; varios países y estados de EE.UU. han cambiado sus reglas de horario de verano en las últimas décadas. Turquía, Rusia y otros han cambiado sus offsets estándar por completo.
- Las fechas de inicio y fin del horario de verano se desplazan. Estados Unidos movió sus límites de horario de verano en 2007. Cualquier sistema que codificó la regla antigua produjo silenciosamente horas incorrectas durante semanas cada año.
Si almacenas solo un offset, no puedes responder a la pregunta "¿cuál será la hora local en Santiago el 15 de noviembre del próximo año?" — porque la respuesta depende de reglas que quizás ni siquiera estén finalizadas aún. Almacenar el identificador de zona (America/Santiago) junto con la base de datos permite que el software calcule el offset correcto para cualquier momento, pasado o futuro, y lo recalcule automáticamente cuando las reglas cambien.
Esta es la propuesta de valor central: la base de datos tz separa la identidad de un lugar de las reglas siempre cambiantes que determinan su reloj.
Cómo se mantiene
El mantenimiento ocurre de forma abierta. Los cambios propuestos — una nueva regla de horario de verano, una fecha histórica corregida, un anuncio gubernamental — se discuten en la lista de correo pública tz, donde los colaboradores citan gacetas oficiales, informes de noticias y decretos gubernamentales como evidencia. La precisión se toma en serio; los cambios a datos históricos en particular se examinan minuciosamente contra fuentes primarias.
Las versiones se etiquetan con un año y una letra: 2024a, 2024b, 2024c, y así sucesivamente. El número es el año; la letra se incrementa con cada lanzamiento ese año. Debido a que los gobiernos anuncian los cambios de hora en sus propios horarios impredecibles, no hay una cadencia de lanzamiento fija — un año tranquilo puede tener dos lanzamientos, mientras que un año de agitación política tiene muchos. Se espera que los sistemas se actualicen rápidamente, ya que una base de datos desactualizada puede significar mostrar la hora incorrecta después de que un cambio de regla entre en vigor.
Quién depende de ella
Casi todo.
- Sistemas operativos. Las distribuciones de Linux incluyen
tzdatacomo un paquete central. macOS obtiene sus datos de zona de la misma fuente. Windows utiliza sus propias zonas basadas en el registro por razones heredadas, pero expone zonas IANA a través de la biblioteca ICU y las API modernas. - Lenguajes de programación. Efectivamente, toda biblioteca madura de fecha/hora lee o incluye la base de datos tz:
zoneinfode Python,java.timede Java, el proyecto ICU, PostgreSQL, los motores JavaScript a través de ICU, Ruby, PHP, y muchos más. - Aplicaciones. Calendarios, sistemas de reservas, plataformas de negociación financiera, herramientas de análisis de registros y servicios de programación dependen de ella, generalmente sin que sus desarrolladores lo piensen.
Esta ubicuidad es exactamente por qué la base de datos es tan importante. Una única fuente de verdad compartida y cuidadosamente mantenida significa que una reunión programada en un sistema se muestra correctamente en otro, a través de sistemas operativos y lenguajes, décadas en el pasado o futuro.
Si quieres explorar las zonas en sí mismas, consulta la lista completa de Zonas horarias IANA o mira cómo se mapean a través del globo en nuestro directorio de Todas las zonas horarias.
Preguntas frecuentes
¿Es la base de datos tz lo mismo que tzdata, zoneinfo y la base de datos Olson?
Sí. Todos estos son nombres para el mismo proyecto. "tzdata" generalmente se refiere a los archivos de datos tal como se empaquetan para un sistema operativo, "zoneinfo" al directorio binario compilado, y "base de datos Olson" es el nombre histórico más antiguo en honor al fundador Arthur David Olson. Hoy el nombre oficial es la Base de Datos de Zonas Horarias de IANA.
¿Con qué frecuencia se actualiza la base de datos?
No hay un horario fijo. Los lanzamientos son provocados por eventos del mundo real — un gobierno que cambia sus reglas de horario de verano o su offset estándar, o una corrección a datos históricos. Algunos años ven un solo lanzamiento; otros ven varios. Cada uno se nombra como 2024a, 2024b, incrementando la letra a lo largo del año.
¿Por qué nombra zonas con ciudades como America/New_York?
Las ciudades son geográficamente fijas y tienen historiales continuos de medición del tiempo, mientras que los países, las fronteras y los offsets cambian con el tiempo. Usar una ciudad representativa le da a cada zona un identificador estable y políticamente neutral que sigue siendo válido incluso cuando las reglas subyacentes de horario de verano o offset cambian.
¿Puedo simplemente almacenar un offset UTC en lugar de un nombre de zona?
Solo para un instante fijo único. Para eventos futuros o recurrentes debes almacenar el identificador de zona, porque los offsets cambian con el horario de verano y las decisiones gubernamentales. El nombre de zona más la base de datos permite que el software calcule el offset correcto para cualquier fecha automáticamente.
¿Quién dirige el proyecto ahora?
Es publicado por IANA, que asumió la administración en 2011, y coordinado por Paul Eggert con una comunidad de colaboradores que trabajan a través de la lista de correo pública tz. El trabajo técnico sigue siendo un esfuerzo colaborativo impulsado por voluntarios.