IANA timezone

Un IANA timezone es un identificador canónico como Europe/London, America/New_York, o Asia/Tokyode la base de datos IANA Time Zone (también llamada “tzdata” o “base de datos Olson” en honor a su mantenedor original, Arthur David Olson).

Cada entrada captura todas las reglas históricas y actuales del desplazamiento UTC y el comportamiento del horario de verano para una región. “Europe/London” codifica: GMT (UTC+0) en invierno, BST (UTC+1) en verano, las fechas precisas de transición de horario de verano y las particularidades históricas anteriores a 1971. Introducir una fecha y una zona en cualquier lenguaje de programación moderno devuelve el desplazamiento correcto porque tzdata está integrado en el sistema operativo.

La convención de nomenclatura es Región/Ciudad, donde Región es uno de Africa, America, Antarctica, Asia, Atlantic, Australia, Europe, Indian, Pacific, más los especiales UTC, Etc/GMT, etc. Ciudad es una ciudad canónica dentro de la zona — Istanbul representa toda Turquía, New_York representa la zona horaria del Este de EE. UU., y así sucesivamente.

El conversor de zonas horarias de Convertitive trabaja contra los datos tz a nivel de sistema operativo del navegador mediante Intl.DateTimeFormat, por lo que las transiciones de horario de verano y los cambios de desplazamiento siempre están actualizados sin que Convertitive tenga que publicar actualizaciones.

Ejemplo práctico

Estás programando una reunión semanal recurrente del equipo a las “martes 09:00 hora de Nueva York” para asistentes en NYC, Londres y Tokio. Almacena la reunión como { rrule: "FREQ=WEEKLY;BYDAY=TU", time: "09:00", tz: "America/New_York" }. El calendario del asistente de Londres resuelve cada ocurrencia: en enero, NY está en EST (UTC−5) y Londres en GMT (UTC+0), por lo que la reunión es a las 14:00 en Londres. En marzo (después de que EE. UU. cambia al horario de verano pero antes de que lo haga la UE), NY está en EDT (UTC−4) y Londres en GMT, por lo que la reunión es a las 13:00 en Londres — una hora antes. En junio, ambos en horario de verano, NY EDT (UTC−4) y Londres BST (UTC+1), así la reunión es a las 14:00 en Londres de nuevo. Tokio (UTC+9, sin horario de verano) ve la reunión cambiar entre las 22:00 y las 23:00 dependiendo de la temporada. Imagina que el equipo hubiera almacenado la reunión como “14:00 UTC” — el asistente de NY experimentaría el horario de la reunión desplazándose hacia atrás y hacia adelante con el horario de verano, y la convención “martes 9 AM” se rompería silenciosamente dos veces al año.

Cuándo y por qué importa

Los IANA timezones importan en el momento en que un sistema procesa fechas de más de un usuario, más de una ubicación o más de una temporada. El error a evitar en el almacenamiento es usar desplazamientos fijos — “Asia/Karachi” sobrevive a una futura reintroducción del horario de verano; “UTC+5” no. El error a evitar en la visualización es renderizar marcas de tiempo sin especificar la zona de destino — un registro de backend que muestre “2026-05-22 14:30” sin etiqueta de zona es ambiguo e imposible de buscar. El error a evitar en la lógica de negocio es realizar aritmética de “agregar 1 día” en UTC en lugar de en hora local alrededor de las transiciones de horario de verano. Las bibliotecas modernas de fecha y hora (la API Temporal de JavaScript, zoneinfo de Python, java.time de Java) manejan esto correctamente cuando se les dan identificadores IANA. Referencia: RFC 6557 — Procedimientos para mantener la base de datos de zonas horarias.

El ciclo de versiones de tzdata:las versiones de tzdata se identifican por año + letra minúscula — 2024a, 2024b, 2025a, etc. Las versiones se publican bajo demanda, generalmente 4-8 veces al año, cada vez que un gobierno cambia las reglas de horario de verano o el desplazamiento horario de una región. Cambios recientes notables: México abolió el horario de verano en todo el país en 2022; Rusia abandonó y restauró el horario de invierno permanente en múltiples revisiones; Líbano tuvo un inicio de horario de verano retrasado una semana en 2023 debido a una disputa política. Cada sistema operativo recoge los cambios a través de actualizaciones rutinarias de paquetes — pero los dispositivos IoT y los teléfonos antiguos que no se actualizan automáticamente pueden desincronizarse, lo que lleva al clásico problema de “mi reloj despertador tiene una hora de retraso” durante la primera semana tras un cambio de regla de horario de verano.

Por qué nunca almacenar desplazamientos directamente:el error más común en el código de fecha y hora es almacenar “UTC+2” en lugar de Europe/Istanbul. El desplazamiento captura un hecho puntual sobre la zona, pero no las reglas. Si Turquía reintroduce el horario de verano (lo abolió en 2016, pero los cambios de reglas son comunes en la región), cada registro con “UTC+2” se vuelve incorrecto de la noche a la mañana. Almacena el identificador de zona IANA y deja que la búsqueda calcule el desplazamiento correcto para cada marca de tiempo. Relacionado: UTC, segundo intercalar. Referencia: Base de datos IANA Time Zone.