Despliega agentes programados a tiempo: contrato de zona horaria y pruebas de próxima ejecución

Un agente programado puede verse correcto en la interfaz y, aun así, activarse en la hora equivocada. La programación de automatización de Codex Desktop mostraba una regla semanal recurrente en términos de hora local, pero su cálculo de próxima ejecución trataba BYHOUR como UTC. Una automatización semanal de Codex Desktop mostrada como viernes a las 16:00 calculó una próxima ejecución de 18:00 Europe/Paris el 2026-06-05. Añadir DTSTART;TZID=Europe/Paris a la RRULE reportada de Codex Desktop no cambió la próxima ejecución calculada.

El contrato de zona horaria mantiene la hora honesta

El contrato tiene cuatro partes: declarar la zona prevista, almacenar y calcular en UTC, mostrar la hora local para las personas y afirmar la próxima ejecución tras migraciones, cambios de horario y modificaciones de configuración del proveedor. Separa la etiqueta humana del cálculo del motor.

Declara la zona prevista en la definición de la programación. El campo indica la zona que el operador usó al configurar la tarea. Usa un identificador de zona con nombre, no un desplazamiento fijo. Una zona con nombre incluye la regla de horario de verano. Un desplazamiento fijo no. El motor no debe reinterpretar una hora local después de guardar la tarea.

Almacena y calcula en UTC. Cada marca de tiempo interna, intervalo y cálculo de próxima ejecución usa la misma zona canónica. Mantén separados el valor almacenado y el valor mostrado.

Muestra la hora local para las personas. El operador ve la hora local prevista mientras el motor conserva el valor canónico. La visualización es para las personas, no para el motor.

Nombra al responsable de la programación en las notas de la versión. El responsable revisa la afirmación de próxima ejecución antes de la primera ejecución en producción y puede explicar por qué se desplazó la próxima ejecución.

Ese contrato previene la división común: la interfaz indica una hora y el motor calcula otra. Esa división es el error. Solo aparece tras la primera ventana perdida. El operador ve la discrepancia antes de que el agente se ejecute.

Las pruebas de próxima ejecución detectan el desplazamiento silencioso

Ejecuta el programador contra un reloj fijo. Afirma la próxima ejecución antes de desplegar. La prueba imprime la próxima ejecución en UTC y la hora local prevista, y falla si no coinciden. La afirmación es la puerta de la versión.

Registra la próxima ejecución calculada en el momento del despliegue. El registro de la versión muestra la próxima ejecución antes de la primera y establece una línea de base para la siguiente revisión.

Afirma la próxima ejecución tras una migración. La comparación antes y después falla si la próxima ejecución se desplaza sin una solicitud de cambio. Afirma la próxima ejecución tras un cambio de horario. La prueba cubre la transición y la semana siguiente.

Emite una alerta cuando la próxima ejecución se desplaza sin una solicitud de cambio. La notificación indica la antigua próxima ejecución, la nueva próxima ejecución y el responsable.

Una afirmación de próxima ejecución compara la programación mostrada, el valor almacenado y la ejecución calculada. Si la interfaz del proveedor y el motor no coinciden, bloquea la versión. Trata cualquier visualización del proveedor como una afirmación, no como una garantía. Verifica la próxima ejecución calculada antes de publicar.

Los cambios de configuración del proveedor también rompen las programaciones

Comprueba el comportamiento del programador del proveedor antes de la versión. La lista de verificación cubre la interfaz, la programación almacenada, la próxima ejecución calculada y la configuración del tiempo de ejecución del agente.

OpenClaw, un tiempo de ejecución de agentes, tiene sus propios modos de fallo. Un despliegue de OpenClaw alojado en UTC con activeHours configurado usando hora del Este puede ver su ventana de heartbeat desplazada 4-5 horas. La configuración de activeHours está en la zona equivocada para el host.

OpenClaw cambia al modo de agente explícito cuando cualquier agente en agents.list[] tiene un bloque heartbeat, por lo que los agentes que dependen de agents.defaults.heartbeat no ejecutan heartbeats. El cambio de modo es fácil de pasar por alto. Comprueba el modo antes de culpar al modelo.

OpenClaw v2026.3.11 tenía un error de marca de tiempo obsoleta causado por una guarda en appendCronStyleCurrentTimeLine que bloqueaba la actualización de marcas de tiempo después de que ya existiera una línea 'Current time:'. Un incremento de versión puede cambiar lo que el agente ve. Prueba la línea de reloj, no solo la entrada de cron.

Revisa las notas de versión por cambios en el programador. La lista de verificación indica la versión, la configuración y la afirmación de próxima ejecución. Vuelve a ejecutar la prueba de próxima ejecución tras cada migración, cambio de horario y modificación de configuración del proveedor. Mantén la afirmación en la pipeline de compilación para que la programación no pueda desplazarse sin revisión.