El generador de cron ensambla expresiones crontab de cinco campos — minuto, hora, día del mes, mes, día de la semana — la sintaxis que lee todo daemon cron en Linux y Unix. Rellena los cinco campos con la notación que cron realmente acepta: un comodín, un valor único, un rango como 9-17, un paso como */15 o 0-30/5, o una lista separada por comas, además de los nombres de meses y días de la semana que el propio cron reconoce (ene-dic, dom-sáb, e incluso rangos como lun-vie y ene-mar). Cada campo se valida contra sus límites reales — minutos 0–59, horas 0–23, días 1–31, meses 1–12, días de la semana 0–7 con el 7 significando domingo exactamente como dice la página de manual — y la entrada inválida se rechaza con un mensaje que dice qué está mal, nunca se «arregla» en silencio. A partir de la especificación analizada, la herramienta deriva tres cosas importantes: la expresión canónica para pegar en crontab, una descripción en lenguaje natural de cuándo se ejecuta el trabajo, y el próximo tiempo real de ejecución, calculado minuto a minuto contra las reglas reales de coincidencia del daemon. Ese último paso es donde mienten la mayoría de los generadores, y este es cuidadoso de tres maneras. La próxima ejecución se calcula en la zona horaria local de tu navegador, y la página lo dice, porque un daemon cron en un servidor corre en la zona horaria del servidor. Se respeta la regla OR clásica: cuando tanto el día del mes como el día de la semana están restringidos, cron se dispara cuando EITHER coincide — sorprendente, documentada y mostrada en la descripción. Y las fechas imposibles se informan con honestidad: un trabajo para el 31 de febrero no encuentra próxima ejecución dentro del horizonte de 366 días y te lo dice en lugar de hacer un bucle infinito. Todo se calcula localmente — nada de lo que escribes se sube ni se almacena. Úsalo cuando programes una copia de seguridad, un build, un informe o un trabajo de base de datos y quieras la expresión correcta antes de que entre en producción.
Preguntas frecuentes
¿Qué significa la regla OR para día-del-mes y día-de-la-semana?
Cuando ambos campos están restringidos — por ejemplo día-del-mes 1 y día-de-la-semana 5 — cron se ejecuta cuando CUALQUIERA de los dos coincide, así que el trabajo se dispara el día 1 del mes Y todos los viernes. Esto sorprende a casi todo el mundo, y es exactamente como se comportan Vixie cron y sus descendientes. La herramienta la respeta en el cálculo de la próxima ejecución y la declara en la descripción.
¿Qué zona horaria usa el cálculo de la próxima ejecución?
La zona horaria local de tu navegador. Un daemon cron corre en la zona horaria del servidor, que puede ser UTC o cualquier otra — la página dice la zona horaria explícitamente, y debes compararla con el servidor que ejecutará el trabajo antes de confiar en la hora impresa.
¿Por qué se acepta 7 para domingo, y 0 también es domingo?
crontab(5) define día-de-la-semana como 0–7, donde tanto 0 como 7 significan domingo; 7 es una forma heredada que algunos sistemas aceptan. La herramienta acepta ambos y los normaliza al mismo valor para la coincidencia.
¿Dónde está el campo de segundos?
El formato estándar de cinco campos no tiene campo de segundos — la unidad más pequeña es el minuto. Algunas herramientas (como Quartz y ciertas bibliotecas de Node) extienden cron con segundos, pero esas extensiones no son portables entre daemons, así que este generador se ciñe al formato portable de cinco campos.
¿Qué ocurre con fechas imposibles como el 31 de febrero?
Cron simplemente nunca las dispara. La herramienta calcula la próxima ejecución sobre un horizonte de 366 días y, cuando no existe ninguna — como con el 31 de febrero — lo informa con honestidad en lugar de mostrar una fecha que nunca llegará.