El horario de verano (DST, por sus siglas en inglés) consiste en adelantar los relojes una hora durante los meses más cálidos para que las tardes tengan más luz natural. En primavera los relojes se adelantan una hora y en otoño se atrasan para volver al horario estándar. El concepto fue propuesto seriamente por primera vez por George Vernon Hudson en 1895 y se adoptó de forma generalizada durante la Primera Guerra Mundial como medida de ahorro energético.
Hoy en día, aproximadamente 70 países aplican alguna forma de horario de verano, aunque la práctica se concentra en Norteamérica y Europa. La mayor parte de África, Asia y Sudamérica no cambian sus relojes. Los países cercanos al ecuador experimentan poca variación en las horas de luz a lo largo del año, lo que hace innecesario el cambio horario. Japón, China e India son ejemplos destacados de grandes economías que operan con horario estándar fijo durante todo el año.
Estados Unidos y Canadá inician el horario de verano el segundo domingo de marzo a las 2:00 AM hora local y lo finalizan el primer domingo de noviembre. La Unión Europea realiza la transición el último domingo de marzo y el último domingo de octubre, con los cambios ocurriendo a la 1:00 AM UTC de forma simultánea en todos los estados miembros. Esto significa que hay varias semanas al año en las que la diferencia horaria entre Norteamérica y Europa difiere en una hora respecto al desfase habitual.
Los países del hemisferio sur que observan el horario de verano lo hacen en el calendario opuesto. Australia inicia su horario de verano a principios de octubre y lo termina a principios de abril. Nueva Zelanda comienza a finales de septiembre y finaliza a principios de abril. Esto genera un periodo en el que la diferencia horaria entre Sídney y Londres oscila dos horas respecto a su desfase de pleno invierno, porque una ciudad está en horario de verano mientras la otra se encuentra en horario estándar.
Las reglas exactas de transición cambian con el tiempo. Estados Unidos extendió el horario de verano varias semanas en 2007 bajo la Ley de Política Energética de 2005. Cualquier software que maneje conversiones de hora debe usar una copia actualizada de la base de datos de zonas horarias IANA para reflejar las reglas vigentes de cada jurisdicción.
Las transiciones del horario de verano son una de las principales causas de reuniones internacionales perdidas. Una llamada semanal recurrente entre Tokio y Londres que funciona perfectamente durante meses se desfasará una hora de repente cuando el Reino Unido cambie al horario de verano británico. El organizador puede no darse cuenta del cambio hasta que alguien se conecta una hora tarde o una hora temprano.
El enfoque más seguro es programar reuniones internacionales recurrentes usando una hora UTC fija en lugar de una hora local. Si una reunión se establece a las 09:00 UTC cada martes, siempre será a las 09:00 UTC independientemente de los cambios horarios. Los participantes en regiones con horario de verano verán que la reunión se desplaza una hora en su calendario local, pero la hora real de la reunión permanece constante. Las aplicaciones de calendario con soporte de zonas horarias manejan esto automáticamente cuando el evento se crea con un anclaje UTC.
La evidencia creciente sugiere que el cambio bianual de reloj causa daños medibles. Estudios han documentado aumentos en infartos, accidentes de tráfico y lesiones laborales en los días posteriores a la transición de primavera. Los investigadores del sueño argumentan que el cambio abrupto de una hora altera los ritmos circadianos, con efectos que duran hasta dos semanas en algunos individuos.
Varias jurisdicciones se han movido hacia la abolición del horario de verano. La Unión Europea votó en 2019 para eliminar los cambios obligatorios de reloj, aunque la implementación se ha retrasado. En Estados Unidos, la Ley de Protección Solar fue aprobada por el Senado en 2022 proponiendo un horario de verano permanente, pero no avanzó en la Cámara de Representantes. Arizona y Hawái ya no observan el horario de verano. A medida que más regiones consideran la abolición, el mosaico de reglas probablemente se volverá aún más complejo durante el periodo de transición.
El horario de verano genera errores sutiles en el software que maneja tiempo. Un día no siempre tiene 24 horas: el día del adelanto de primavera tiene solo 23 horas, y el día del atraso de otoño tiene 25. El código que asume que un día equivale exactamente a 86.400 segundos producirá resultados incorrectos dos veces al año. De forma similar, la hora local 2:30 AM no existe en el día del adelanto, y la hora local 1:30 AM ocurre dos veces en el día del atraso.
El consejo estándar para desarrolladores es almacenar todas las marcas de tiempo en UTC y convertir a hora local solo en la capa de presentación. Al mostrar eventos futuros, se debe almacenar la hora local prevista junto con el identificador de zona horaria IANA (no solo el desfase UTC), de modo que si las reglas del horario de verano cambian antes de que ocurra el evento, el sistema pueda recalcular el equivalente UTC correcto. Bibliotecas como Luxon, date-fns-tz y java.time de Java manejan estos casos especiales correctamente cuando se usan con datos de zonas horarias actualizados.
¿Te resultó útil este artículo?
Las tareas cron configuradas en hora local se ejecutan dos veces o se saltan silenciosamente durante las transiciones de horario de verano. Este artículo repasa los modos de fallo, el caso a favor de ejecutar programaciones en UTC, el campo timeZone de Kubernetes CronJob y cómo los planificadores en la nube gestionan el mismo problema.
El horario de verano ha ido perdiendo apoyo político durante una década. La Unión Europea votó abolir el cambio de hora en 2019, y la evidencia médica sobre infartos y alteraciones circadianas sigue acumulándose. Este artículo analiza la ciencia, el mito energético y lo que cada región ha decidido realmente.
El cambio horario crea dos momentos anómalos al año: horas inexistentes durante el adelanto de primavera y horas duplicadas durante el atraso de otoño. Este artículo cataloga los errores resultantes en programación de eventos, aritmética de duración, eventos recurrentes, almacenamiento en base de datos y estrategia de pruebas.