Skip to content

Data study

Cincuenta años de cambios de horario de verano (DST): un recorrido por el historial de IANA tzdata

Se supone que el DST es una política ya fijada. El registro de cambios de IANA tzdata demuestra que no lo es —y no lo será.

By Published

La mayoría de los desarrolladores de software tratan los horarios de DST como conocimiento estático. No lo son. La base de datos IANA tzdata —la fuente canónica de las reglas de zona horaria en todo el mundo— ha publicado múltiples actualizaciones cada año durante décadas. Entre 1990 y 2024, la base de datos registró cambios de reglas para al menos 39 entidades nacionales o subnacionales distintas. Este artículo recorre los cambios más importantes, por qué ocurrieron y qué enseñan sobre el diseño de los sistemas de planificación.

Qué significa «un cambio de regla»

IANA tzdata almacena las reglas de zona horaria como pares de (período vigente, comportamiento de desfase/DST). Un cambio de regla añade una nueva entrada —«a partir de la fecha X, esta zona ya no observa el DST»— y deja intactas las reglas históricas. Los sistemas que dependen de una planificación precisa deben cargar actualizaciones con regularidad; uno que carga una instantánea de tzdata de 2010 calculará mal cualquier cómputo con conciencia del DST para cualquier cambio de regla posterior a 2010.

Cambios de alto impacto seleccionados

Rusia (2011, 2014)

En 2011, la Federación Rusa pasó permanentemente al horario de verano, eliminando los cambios de reloj. En 2014 la política se invirtió: Rusia cambió permanentemente al horario estándar (hora de invierno). Dos cambios de regla en tres años para un país de 11 zonas horarias afectaron a todos los servicios orientados a Rusia. Outlook, los servidores Exchange y los trabajos programados en bases de datos fallaron en oleadas ambos años.

Brasil (2019)

Brasil puso fin al DST a finales de 2019 tras observarlo durante ~80 años. La decisión se tomó por motivos de política energética —el ahorro que el DST proporcionaba históricamente se había erosionado a medida que los patrones de carga máxima cambiaron. Aproximadamente 70 millones de personas en los estados del sur y sureste afectados tienen ahora el mismo desfase todo el año.

Egipto (2010-2015, intermitente)

Egipto canceló el DST en 2010, lo restableció para la temporada 2014-2015 (con una notable suspensión a mitad del Ramadán) y luego lo canceló de nuevo. El caso de 2014 es un ejemplo célebre en los despliegues de software: el anuncio del cambio de regla llegó tan cerca de la fecha del adelanto de hora que muchos sistemas no lo captaron; los usuarios egipcios vieron sus teléfonos mostrando horas con 1-2 horas de desajuste durante días.

Samoa (2011)

Samoa pasó de UTC-11 a UTC+13 saltándose completamente el 30 de diciembre de 2011. El país cruzó efectivamente la línea internacional de cambio de fecha un jueves por la mañana, saltando directamente al sábado. El comercio y el transporte marítimo con Australia y Nueva Zelanda impulsaron el cambio; las empresas samoanas tenían previamente un desajuste de 21 horas de día hábil con sus principales socios comerciales.

Türkiye / Turquía (2016)

Turquía abandonó el DST en 2016, fijando el país en UTC+3 todo el año. Las razones citadas: el ahorro energético es cuestionable, la oscuridad matutina en invierno es impopular. Los proveedores de software se apresuraron a publicar parches antes de la fecha de atraso de otoño que ya no existía.

Marruecos (2018 en adelante)

Marruecos cambió al DST permanente en 2018 (UTC+1 todo el año, suspendido cada año durante el Ramadán, cuando el país vuelve a UTC+0 durante el mes). El doble cambio impulsado por el Ramadán cada año es una de las reglas más complejas en IANA tzdata —su fecha se desplaza ~11 días anualmente con respecto al calendario gregoriano.

Directiva de horario de verano de la UE (2018-2021, aún pendiente)

La Comisión Europea propuso poner fin al DST en toda la UE en 2018. El Parlamento Europeo lo aprobó en 2019 con 2021 como fecha de aplicación. Nunca se llegó a un acuerdo entre los Estados miembros sobre qué hora observar permanentemente (su hora de verano o su hora estándar); el cambio no se ha producido. A fecha de 2026, la UE sigue observando el DST, aunque persiste el consenso político para ponerle fin.

EE. UU.: Sunshine Protection Act (2022)

El Senado de EE. UU. aprobó por unanimidad un proyecto de ley para hacer permanente el horario de verano en marzo de 2022. La Cámara de Representantes no lo tramitó. El proyecto se reintrodujo en 2023 y tampoco fue aprobado. EE. UU. sigue adelantando y atrasando el reloj.

El problema del volumen

Recuento de cambios de regla importantes por decenio (extracto del archivo NEWS de IANA tzdata):

DecenioNúmero aproximado de cambios importantes
Años 90~30 (repúblicas possoviéticas, unificación del Yemen, etc.)
Años 2000~50 (armonización de la UE, varios cambios en África y América del Sur)
Años 2010~70 (Rusia dos veces, Egipto varias veces, Samoa, Turquía, Marruecos, Brasil, etc.)
2020-2024~25 (caos en Líbano en 2023, Yukón, ajustes de Ucrania en tiempos de guerra)

La tendencia es aproximadamente estable: entre 5 y 10 cambios de regla significativos al año en todo el mundo. Un sistema que no refresca tzdata anualmente será incorrecto para ~3-5 % de la población mundial si usa una base de datos de 5 años de antigüedad.

Qué cuesta esto en la práctica

Tres categorías de fallos observados en los postmortems de incidentes de tzdata desactualizado:

  • Calendarios y reuniones. Las invitaciones a reuniones entre zonas horarias muestran la hora local incorrecta. El asistente con el teléfono desactualizado pierde la llamada.
  • Marcas de tiempo en bases de datos e informes. Los trabajos cron se ejecutan una hora antes o después. Los informes de agregación diaria incluyen o excluyen transacciones a través del límite fantasma del DST. Sutil pero costoso en la conciliación financiera.
  • Ventanas de límite de tasa de API y trabajos programados. Todo lo que define «medianoche en la zona X» se equivoca por una hora. La facturación de SaaS, los programas de rotación de registros y trabajo de back-end similares fallan silenciosamente.

Qué hacer al respecto

  1. Usar la base de datos IANA, no las abreviaturas. Almacene las zonas como America/New_York, no como EST. Las abreviaturas no codifican los cambios de regla; los nombres IANA sí.
  2. Mantener tzdata actualizado. Los sistemas operativos publican actualizaciones de tzdata mensual o trimestralmente. Asegúrese de que los contenedores, los tiempos de ejecución de funciones y las aplicaciones empaquetadas las reciban.
  3. Volver a renderizar los eventos programados ante un cambio de regla. Una reunión programada en 2024 para repetirse «todos los lunes a las 14:00, hora de Nueva York» realiza un seguimiento correcto del DST. Una reunión programada en 2024 para repetirse «todos los lunes a las 14:00 EST» (la abreviatura) falla dos veces al año.
  4. Probar con fechas adversas. Las tres semanas cada primavera en que los horarios de DST de EE. UU. y la UE no coinciden, las fechas en que un país cambió recientemente sus reglas, el solapamiento del segundo intercalar si está presente. Los conjuntos de pruebas reales incluyen estos casos.

Para la planificación práctica entre zonas, use nuestro conversor de zona horaria (usa tzdata del navegador) y el planificador de reuniones (gestiona los desajustes de DST automáticamente).

Fuentes

Archivo NEWS de la base de datos IANA tzdata (Eggert et al., 1986-2024); informes archivados de política de DST de timeanddate.com; boletines de horario de verano y zona horaria de Microsoft; avisos de la OACI sobre referencias horarias aeronáuticas.

Related

Published May 16, 2026