Cómo programar una tarea cuando el cambio de hora repite o elimina una hora

Distingue hora de negocio e intervalo

«Cada día a las 08:00 de la oficina» y «cada 24 horas» son requisitos diferentes durante el cambio de hora. Para el primero, conserva una zona IANA como Europe/Madrid y la hora local deseada; un desplazamiento fijo como UTC+1 no representa sus cambios estacionales. Para un intervalo, utiliza la modalidad documentada del servicio que mida esa duración. UTC puede simplificar una cadencia técnica, pero fijar la misma hora UTC todo el año desplaza la hora local de una tarea ligada a apertura o cierre.

Aprueba una salida para el salto y otra para la repetición

En un ejemplo hipotético, un cierre diario previsto a las 02:30 cae en una franja afectada por el cambio de hora. Si esa hora no existe, decide entre omitir la ejecución, trasladarla al primer instante válido o llevarla a otra hora acordada. No confundas esas dos últimas opciones: desplazar una hora y esperar al final del salto pueden producir instantes distintos. Si la hora aparece dos veces, decide si corresponde la primera, la segunda o ambas. Registra quién autoriza la política y qué periodo cierra cada ejecución; una segunda aparición del reloj no constituye por sí sola otra jornada de negocio.

Contrasta la política con el producto real

Google Cloud Scheduler advierte de anomalías al evaluar horarios de reloj local durante estos cambios; no promete en esa guía una política universal de recuperación. EventBridge Scheduler sí documenta para cron que omite la hora inexistente y ejecuta una sola vez ante la repetición. Son contratos de productos concretos. Si no cumplen tu política, cambia la franja cuando sea aceptable o diseña una capa que calcule ocurrencias y concilie las pendientes. No presupongas que el planificador permite seleccionar cualquier alternativa. Mantén actualizados los datos horarios: IANA incorpora cambios de reglas decididos por las autoridades.

Comprueba ambas transiciones con instantes verificables

En pruebas, calcula las ocurrencias de una ventana que incluya el salto de primavera y otra que incluya la repetición de otoño para la zona elegida. Comprueba cuántas ejecuciones se esperan y qué instante UTC corresponde a cada una. Incluye los días anterior y posterior para detectar un desplazamiento permanente. No basta con cambiar la zona de visualización de un log: verifica el calendario calculado y el efecto final con el mismo motor o servicio que utilizarás.

Registra lo previsto y lo que ocurrió

Guarda identificador de tarea, zona IANA, regla y versión de política, fecha de negocio, instante previsto resuelto, inicio real y resultado. Muestra la hora local con su desplazamiento y el instante UTC: dos entradas «02:30» necesitan distinguirse. Separa las ocurrencias autorizadas de los reintentos técnicos para comprobar el número de efectos. Avisa si falta una ejecución exigida o aparece una adicional, y asigna la recuperación al responsable. Así puedes demostrar que se cumplió la decisión del negocio incluso cuando cambió el reloj.

Fuentes y documentación

• Google Cloud Scheduler: cron y zona horaria — Advierte de anomalías por horario de verano al evaluar el reloj local; UTC se recomienda para determinadas necesidades de cadencia.
• EventBridge Scheduler: tipos de programación y horario de verano — Documenta omisión de horas inexistentes, una ejecución en la repetición y diferencia entre cron y duraciones de 24 horas.
• IANA: Time Zone Database — Mantiene reglas históricas y actualizaciones de zonas, desplazamientos y horario de verano.