Español

Herramientas de desarrollo · Generador de Crontab

Cron y horario de verano: por qué un trabajo 02:30 puede saltarse o ejecutarse dos veces

· Por qué es importante

cron zonas horarias horario de verano

Un 02:30 candidato a reloj cruzando un espacio en la línea de tiempo de un reloj de pared
Ilustración de vector original de ToolAcre

Dos veces al año el reloj de pared salta y un trabajo cron programado en el espacio o la superposición se comporta inesperadamente. Esta publicación explica qué hacen los crons derivados de Vixie, qué hacen otros y cómo programarlos.

Un candidato de vista previa faltante puede ocurrir cuando la zona seleccionada no tiene tal hora de reloj de pared

La hora diaria del reloj de pared puede estar ausente en una fecha cuando una zona horaria seleccionada adelanta sus relojes. ToolAcre representa ese caso al no devolver ningún instante para el minuto local inexistente y omitirlo en la lista de próxima ejecución. La expresión sigue siendo válida; un candidato de calendario simplemente no puede convertirse en un instante real en esa zona.

Este comportamiento se implementa en `wallClockToEpoch`, que convierte una fecha y hora locales propuestas, formatea el resultado nuevamente en la misma zona y compara cada componente. Una discrepancia devuelve nulo. `nextRuns` ignora los candidatos nulos y continúa su búsqueda, evitando que una hora cercana inventada aparezca como si coincidiera exactamente con el horario.

Los dos eventos: el avance de la primavera que elimina una hora y el retroceso del otoño que repite una

Los cambios de reloj crean dos casos conceptuales: una brecha hacia adelante con tiempos de pared que nunca ocurren y una superposición hacia atrás donde algunas etiquetas ocurren más de una vez. El repositorio tiene pruebas para mantener una hora local diaria durante un cambio hacia adelante y para omitir un horario de primavera inexistente. No contiene un conjunto completo de pruebas de políticas superpuestas.

Ese límite de evidencia es importante porque las implementaciones del programador pueden tomar decisiones distintas. Este artículo describe el algoritmo de vista previa del navegador, no el comportamiento del demonio universal. Antes de depender de una tarea recurrente durante una transición de reloj, lea y pruebe el programador real en el host de destino en lugar de convertir una vista previa en una promesa de ejecución.

ToolAcre omite horas locales inexistentes; no modela todas las políticas de demonios derivadas de Vixie

El libro de trabajo afirmaba que determinados demonios derivados de Vixie ejecutan trabajos omitidos después de un salto y suprimen los duplicados. ToolAcre no hace ninguna de las dos cosas en su código de vista previa: omite un candidato cuyos componentes locales no pueden realizar el viaje de ida y vuelta. No se invoca ningún paquete de demonio y no se modela ninguna política de actualización. Por lo tanto, estas alegaciones operativas se corrigen en lugar de repetirse.

El ejemplo probado de Londres busca 01:30 alrededor del cambio de marzo 2026. Debido a que ese minuto local no existe en la fecha de transición, los días devueltos son las siguientes fechas válidas. Esto prueba el comportamiento de la lista propia de la ruta. No establece qué hace un proceso cron instalado por separado con una línea ya guardada.

El comportamiento de programación comodín en demonios externos está fuera de la evidencia del repositorio

El analizador expande las estrellas a cada valor permitido, pero la conversión posterior del reloj de pared aún decide si una fecha y hora en particular se asigna a un instante. ToolAcre no tiene una regla de demonio externo separada para "trabajos comodín". Todos los candidatos viajan mediante el mismo código de búsqueda de calendario y conversión de zona.

Las descripciones siguen siendo puramente gramaticales: `* * * * *` se lee cada minuto, mientras que un campo de minutos escalonados recibe redacción de pasos. La sentencia no narra la política de transición. Utilice la lista de próxima ejecución para los ejemplos calculados de la herramienta y no infiera una garantía de recuperación, reintento o supresión de duplicados a partir únicamente de la prosa.

Otras implementaciones no se deducen de esta vista previa del navegador

La implementación de la zona se basa en los datos `Intl.DateTimeFormat` expuestos por el navegador o el tiempo de ejecución del nodo. ToolAcre valida un nombre de zona de IANA proporcionado, ofrece la lista compatible del motor cuando está disponible e incluye UTC. No inspecciona BusyBox, orquestadores de contenedores ni productos cron en la nube.

Cuando otro programador no esté de acuerdo, trátelo como una cuestión de dialecto y tiempo de ejecución. Registre su versión, configuración de zona y comportamiento de transición observado. La vista previa del navegador sigue siendo útil como comparación transparente, pero su código no puede responder qué política aplica otro servicio o si ese servicio reintenta el trabajo perdido.

Ejemplo resuelto: elija un tiempo de pared e inspeccione los candidatos calculados de ToolAcre

Un método más seguro es seleccionar la zona de implementación, ingresar la expresión diaria propuesta e inspeccionar las fechas alrededor de la próxima transición conocida en ese entorno. Si un candidato requerido está ausente, elija otro horario de pared o una política de programación que el objetivo documente explícitamente. Vuelva a ejecutar la vista previa después de cambiar la hora.

La fuente incluye un valor preestablecido en 02:30, pero un valor preestablecido es un ejemplo, no una recomendación universal. Su validez depende del calendario y zona seleccionados. Es posible que la ventana de cinco resultados de ToolAcre no abarque una transición distante, por lo tanto, elija un contexto inicial adecuado en las pruebas al auditar el comportamiento de la implementación.

La selección de zona es parte de esta vista previa y se analiza aquí solo como comportamiento de la herramienta.

A diferencia de la separación del libro, el manejo de zonas es directamente parte de la vista previa de esta herramienta. El panel pregunta "Mostrar las siguientes ejecuciones" y advierte que la máquina que ejecuta cron puede usar una zona diferente a la del lector. Al elegir una zona, se cambian los instantes resultantes y se conservan los campos de reloj de pared de la expresión.

La selección configura solo el cálculo del navegador. No escribe una directiva de zona horaria, no actualiza un servidor ni incrusta la elección en la expresión copiada. Conserve la zona prevista en la documentación de implementación adyacente y luego configure el programador real mediante mecanismos probados para ese entorno.

Conclusión: vista previa en la zona prevista sin tratar la lista como una garantía de ejecución

Una lista de próxima ejecución es una salida del modelo de cinco campos, un instante inicial, aritmética del calendario y datos de la zona del navegador. Es valioso para detectar tiempos inexistentes y cambios de hora accidentales. No sigue siendo ni un rastro de demonio ni evidencia de que se haya ejecutado un comando.

Utilice la vista previa para identificar tiempos de muro riesgosos y luego verifique el programador de destino en el límite de transición. La promesa defendible de ToolAcre es limitada: los trabajos diarios permanecen en la hora local seleccionada cuando esa hora existe, y los candidatos locales inexistentes se omiten. Todo lo demás pertenece al sistema implementado.