Analizzatore e generatore di espressioni cron

No. L’espressione viene analizzata e le esecuzioni vengono calcolate nel browser con JavaScript; l’espressione non viene caricata su LeedyBox.

Nel cron di Unix, quando sono limitati sia il giorno del mese sia il giorno della settimana (nessuno dei due inizia con *), un giorno corrisponde se corrisponde uno dei due campi, quindi questa espressione viene eseguita il 13 di ogni mese e ogni venerdì. Lo strumento applica questa regola alle espressioni Unix, e «Pianificazione» indica allora «basta uno dei due». Per le espressioni Spring richiede che corrispondano entrambi i campi, mentre Quartz e AWS evitano il problema richiedendo «?» in uno dei due campi. Nel cron di Unix, una soluzione comune è pianificare il job ogni venerdì e controllare la data all’interno del job.

Dipende dal formato. Nelle espressioni Unix e Spring, sia 0 sia 7 indicano la domenica e 1 è il lunedì; in Quartz e AWS, 1 è la domenica e 7 il sabato, quindi lì 1-5 significa da domenica a giovedì. I nomi dei giorni come MON-FRI evitano questa differenza in Spring, Quartz e AWS.

Inserisci solo i campi della pianificazione. Il comando alla fine di una riga di crontab, e il nome utente in /etc/crontab, vengono contati come campi in più, quindi lo strumento segnala un campo non valido o un numero di campi sbagliato. Per AWS, incolla solo i sei campi contenuti tra le parentesi di cron( ), senza cron( ) attorno.

Spring aggiunge un campo dei secondi all’inizio, quindi 0 9 * * 1-5 diventa 0 0 9 * * 1-5. Quartz richiede anche «?» in uno dei campi del giorno e numera la domenica come 1, quindi la stessa pianificazione diventa 0 0 9 ? * MON-FRI. AWS non ha il campo dei secondi, richiede «?» in uno dei campi del giorno come Quartz e aggiunge un anno alla fine: 0 9 ? * MON-FRI *. Se l’espressione Unix limita entrambi i campi del giorno, si basa sulla regola «basta uno dei due» descritta sopra, che questi formati non usano, quindi di solito servono due pianificazioni. Controlla il risultato con il formato di destinazione selezionato e confronta le prossime esecuzioni.

L’espressione è valida, ma nei circa 8 anni successivi in cui lo strumento cerca non è stato trovato alcun orario corrispondente. Le cause tipiche sono date inesistenti, come 0 0 30 2 * (30 febbraio) o il giorno 31 combinato solo con mesi di 30 giorni, e un campo anno che indica un anno passato. Un anno che cade oltre gli 8 anni successivi dà lo stesso messaggio, anche se quella pianificazione può comunque essere eseguita più avanti. Alcuni scheduler, compreso il classico cron di Unix, accettano una data inesistente senza avvisi, e il job non viene eseguito.

Le esecuzioni vengono calcolate per il fuso selezionato in «Fuso orario». Scegli quello usato dal tuo scheduler: crontab di solito segue il fuso orario del server, le regole pianificate di AWS EventBridge usano UTC ed EventBridge Scheduler permette di impostare un fuso orario. Il menu offre il fuso del tuo browser, UTC e una selezione di fusi comuni; se il fuso del tuo scheduler non c’è, scegline uno con lo stesso scarto da UTC e le stesse date di inizio e fine dell’ora legale. Un’esecuzione in un orario saltato quando gli orologi vanno avanti viene esclusa dall’elenco, mentre un orario che si presenta due volte quando tornano indietro viene elencato una sola volta. I demoni cron gestiscono queste ore in modi diversi; cronie, per esempio, può eseguire un job previsto in un’ora saltata subito dopo il cambio. Verifica il comportamento del tuo scheduler oppure usa UTC, che non ha l’ora legale.