Conversor de cron y temporizador systemd | Conversión bidireccional cron ↔ OnCalendar con vista previa de 5 disparos y .timer listo para pegar

Conversor bidireccional entre expresiones cron POSIX y cadenas systemd OnCalendar, con vista previa de los próximos 5 disparos y plantilla .timer o línea crontab lista para pegar. La idea es detectar errores de sintaxis y horarios "ah, no era eso" antes de habilitar la unidad.

💡 Sobre esta herramienta

cron y systemd-timer expresan la misma idea — ejecutar algo en un instante dado — pero con sintaxis muy distintas. cron va de izquierda a derecha: minuto hora día mes día-semana. OnCalendar, en cambio, coloca el día de la semana al principio, luego una tripleta de fecha y al final HH:MM:SS. La conversión mecánica es directa, pero los detalles tropiezan: MON-FRI se vuelve Mon..Fri, */15 se convierte en *:0/15, los seis campos cron (con segundos) no tienen equivalente POSIX, y RandomizedDelaySec simplemente no existe en cron.

La herramienta resuelve esos casos. Expande las formas de lista, rango, paso y nombre (JAN-DEC, MON-FRI) y emite la cadena OnCalendar con prefijo DOW solo cuando hace falta. En el sentido inverso, interpreta los rangos .. y el paso 0/N propios de systemd, separa RandomizedDelaySec en el panel de avisos, y escribe una línea crontab de 5 campos. En ambas direcciones muestra los próximos 5 disparos para 9 zonas habituales, de modo que puedas comprobar contra el reloj del servidor.

La plantilla .timer incluye Persistent=true y AccuracySec=1min como punto de partida sensato para tareas one-shot. Si necesitas otra cosa — disparo cada 30 segundos, sin reposo del sistema — toca esos valores tras copiar el bloque. La unidad asume que existe una .service complementaria con el mismo nombre base.

🧐 Preguntas Frecuentes

Q. ¿Acepta cron de 6 campos con segundos? A. Sí — el primer campo se interpreta como segundos y aparece en HH:MM:SS del OnCalendar. Se muestra un aviso indicando que cron POSIX ignora la precisión sub-minuto; el ajuste solo tiene efecto en el lado systemd.

Q. ¿Por qué no se aceptan @daily o @reboot? A. El analizador maneja la cuadrícula * * * * * explícita. @daily equivale a 0 0 * * *, escríbelo así. @reboot no tiene contraparte en OnCalendar; usa OnBootSec= o OnStartupSec= directamente en la unidad .timer.

Q. ¿Qué pasa con RandomizedDelaySec al pasar a cron? A. Se elimina y se anota un aviso. cron no incluye jitter nativo. Si quieres dispersar la ejecución, añade sleep $((RANDOM % 60)) al inicio del script que invoca cron; la herramienta no lo añade automáticamente.

Q. La vista previa muestra UTC pero mi servidor usa otra zona A. El menú de zonas horarias incluye UTC, la del navegador, JST, ET, PT, GMT, CET (×2) y BRT. Selecciona la que coincida con el reloj del servidor y la lista de 5 disparos se recalcula. Para anclar la zona dentro del propio timer, añade Timezone= a la sección [Timer] después de copiar.

Q. ¿Mantiene el rango Mon..Fri al convertir systemd → cron? A. Lo expande a la lista 1,2,3,4,5 en la línea cron. Si prefieres la forma de rango 1-5, reescríbela a mano; cualquier crond moderno acepta ambas.

Q. ¿Por qué falla mi expresión? A. Los errores aparecen en el panel rojo bajo el campo de entrada con el token problemático (Invalid value: ..., Date must be Y-M-D). La salida queda en -- hasta corregir el error.

📚 Datos Curiosos

systemd-timer apareció con systemd v183 en 2012, pero crond es bastante anterior — la utilidad cron(8) salió con Version 7 Unix en 1979 y lleva ejecutando los lotes del mundo más de cuatro décadas. Conviven porque resuelven cosas ligeramente distintas: el contrato cron es "ejecuta esta línea en este horario", mientras que un timer systemd es solo el disparador que activa una .service definida por separado. Esa indirección añade trabajo para scripts simples, pero compensa cuando necesitas límites de recursos, ficheros de entorno, ordenación de dependencias o registro estructurado en el journal.

OnCalendar parece ISO 8601 a primera vista, pero su comodín * y su operador de paso 0/N son extensiones propias de systemd. El comando systemd-analyze calendar 'Mon..Fri *-*-* 09:30:00' evalúa la expresión y vuelca los próximos disparos — el mismo cálculo que esta página realiza dentro del navegador.