Mag-parse ng cron expression _

Ano ang isang cron expression?

Ang cron expression ay isang compact na scheduling string na nagsasabi sa isang job scheduler kung kailan eksaktong sisisimulan ang isang gawain. Ang format ay ipinanganak noong 1975 sa loob ng Unix V7 cron daemon at halos hindi nagbago mula noon — ang parehong limang-field na grammar ay lumalabas ngayon sa mga Kubernetes CronJob, AWS EventBridge, GitHub Actions workflow, Google Cloud Scheduler, GitLab CI, Jenkins pipeline, at ang crontab binary na kasama pa rin ng bawat Linux distribution. Ang grammar ay naglalagay ng maraming kahulugan sa labintatlo o kaunting karakter, kaya ang isang parser na nagko-convert nito sa simpleng Ingles ay ang pagkakaiba sa pagitan ng isang kumpiyanzang deploy at isang 3 AM rollback.

Paano gumagana ang isang cron expression?

Ang isang standard na cron expression ay may limang space-separated na field na magkasamang nagtatakda ng isang paulit-ulit na iskedyul. Sinusuri ng engine ang kasalukuyang orasan laban sa expression bawat minuto at pinapatakbo ang trabaho kapag nagkatugma ang lahat ng limang field. Ang mga field, mula kaliwa pakanan:

1. Minuto (0–59). Kung aling minuto sa loob ng oras ang tatakbo ang trabaho. Ang 0 ay nangangahulugang sa oras, ang 30 ay nangangahulugang sa kalahating oras, ang */5 ay nangangahulugang bawat limang minuto (00, 05, 10, ...), at ang 15,45 ay nangangahulugang sa quarter past at quarter to.
2. Oras (0–23). Kung aling oras ng araw sa 24-oras na orasan. Ang 0 ay hatinggabi, ang 9 ay 9 AM, ang 17 ay 5 PM. Ang mga hanay (9-17 para sa mga oras ng negosyo) at mga halaga ng hakbang (*/2 para sa bawat ikalawang oras) ay gumagana nang katulad ng para sa mga minuto.
3. Araw ng buwan (1–31). Kung aling araw ng kalendaryo ang tatakbo. Ang 1 ay nangangahulugang ika-1 ng buwan, ang * ay nangangahulugang bawat araw, ang 1,15 ay nangangahulugang ika-1 at ika-15. Maging maingat sa 31 — tahimik nitong nilalaktawan ang mga buwang walang ika-31 na araw.
4. Buwan (1–12 o JAN–DEC). Kung aling mga buwan ang tatakbo. Ang * ay nangangahulugang bawat buwan, ang 1,7 ay nangangahulugang Enero at Hulyo, ang 1-3 ay nangangahulugang Q1 lamang. Ang mga tatlong-titik na pangalan ng buwan ay case-insensitive sa karamihang implementasyon.
5. Araw ng linggo (0–7, kung saan ang parehong 0 at 7 ay nangangahulugang Linggo). Nililimitahan ang pagpapatakbo sa mga tiyak na araw ng linggo. Ang 1-5 ay Lunes hanggang Biyernes, ang 0,6 ay ang katapusan ng linggo, ang MON-FRI ay gumagana sa karamihang parser. Kapag parehong ang day-of-month at day-of-week ay nakatakda sa mga tiyak na halaga, ang classic na cron ay nagpapatakbo sa alinmang tugma (logical OR), na nagugulat sa mga tao sa tuwing mangyari.

Bakit gumamit ng cron expression parser?

• Hulihin ang tahimik na maling pagbasa bago mag-deploy. Ang expression na `0 2 */3 * *` ay nagpapatakbo sa 2 AM bawat ikatlong araw, hindi bawat tatlong minuto — i-paste ito dito at makikita mo iyon sa simpleng Ingles bago ito maipadala sa production.
• Karamihang cloud scheduler ay tumatakbo sa UTC bilang default. Ang pag-preview ng susunod na sampung oras ng pagpapatakbo sa iyong lokal na zone ay nagpapakita ng off-by-one-hour na DST drift bago ito magpapadala ng mensahe sa isang tao ng 3 AM.
• Ang mga shortcut tulad ng `@daily`, `@weekly`, at `@monthly` ay maginhawa ngunit malabo. Ipinapakita sa iyo ng parser ang pinagbabatayan na limang-field na form para malaman mo kung ano ang eksaktong na-iskedyul.
• Ang field-by-field builder ay nagpapahintulot sa iyo na bumuo ng isang iskedyul nang isang column sa isang pagkakataon at panoorin ang paglalarawan na nag-a-update nang live, na mas mabilis kaysa sa muling pagbabasa ng cron man page sa ikasampung pagkakataon.

Saan ginagamit ang mga cron expression?

Lumalabas ang cron syntax saan man kailangan ng paulit-ulit na trabaho sa isang orasan. Tatlo sa mga pinakakaraniwang lugar, na may eksaktong gotcha na pinakakilala ng bawat isa:

• Mga iskedyul ng backup. Ang klasikong `crontab -e` entry na nag-dump ng database sa S3 sa 2 AM araw-araw, o nag-rotate ng `pg_dump` archive sa ika-1 ng bawat buwan. Ang isang linya tulad ng `0 2 * * * /usr/local/bin/backup.sh` ay naipadala sa mas maraming Linux server kaysa sa anupamang linya ng cron sa kasaysayan. Itama ang minuto at oras, i-redirect ang stderr sa isang matibay na lugar, at pinalitan mo na ang isang manu-manong checklist ng isang fire-and-forget na script.
• Mga `schedule` trigger ng GitHub Actions. Ang `on.schedule.cron` key sa `.github/workflows/*.yml` ay tumatanggap ng standard na limang-field na cron, ngunit ang trabaho ay laging tumatakbo sa UTC at tahimik na nilalaktawan ng GitHub ang isang oras ng pagpapatakbo kung abala ang runner queue. Karaniwang pattern: `cron: '0 9 * * 1-5'` para magpadala ng Lunes-hanggang-Biyernes na digest sa 9 AM UTC. I-preview ito dito sa iyong lokal na zone muna para hindi ka mangako ng isang 9 AM London digest na talagang dumarating sa 10 AM sa BST.
• AWS EventBridge Scheduler. Ang mga cron expression ng EventBridge ay kumukuha ng ikaanim na field para sa taon at nangangailangan ng `?` sa halip na `*` sa alinman sa day-of-month o day-of-week field — ang `cron(0 9 ? * MON-FRI *)` ay ang EventBridge translation ng classic na weekday 9 AM standard cron. Ginagamit para sa mga naka-iskedyul na Lambda invocation, pagpapatakbo ng ECS task, at pagsisimula ng Step Function state-machine; ang hindi pagkakatugma sa classic na cron syntax ay ang pinaka-karaniwang pinagmumulan ng mga `ValidationException` error sa mga CloudFormation deploy.

Ano ang hitsura ng isang tunay na cron expression?

Kunin ang 0 9 * * 1-5 — nagpapatakbo sa 9:00 AM, bawat araw ng trabaho. Binabasa ang mga field mula kaliwa pakanan: ang 0 ay ang zeroth minuto ng oras, ang 9 ay 9 AM sa 24-oras na orasan, ang * sa day-of-month ay nangangahulugang bawat araw ng kalendaryo, ang * sa buwan ay nangangahulugang bawat buwan, at ang 1-5 sa day-of-week ay naglilimita ng pagpapatakbo sa Lunes hanggang Biyernes (kung saan 1 = Lunes sa standard na cron numbering). I-paste iyon sa input sa itaas at kinukumpirma ng parser ang Sa 09:00 AM, Lunes hanggang Biyernes na may susunod na sampung petsa ng pagpapatakbo na na-render sa IANA zone na iyong pinili. Ang parehong layunin sa AWS EventBridge syntax ay cron(0 9 ? * MON-FRI *) — pansinin ang field ng taon sa dulo at ang ? kung saan gagamitin ng standard na cron ang *. Ang parehong layunin bilang isang Quartz expression (anim na field na may nangunguna na segundo) ay 0 0 9 ? * MON-FRI. Tatlong magkaibang platform, tatlong magkaibang uri ng form, isang pinagbabatayan na iskedyul.

Ang mga cron expression ay walang pagsisisi sa eksaktong isang paraan: ang isang typo ay nagbibigay sa iyo ng isang syntactically valid na iskedyul na nagpapatakbo sa maling oras, na walang error na mahuhuli sa code review. Ang pagbabasa ng `0 0 1 * *` at pag-alam na ito ay tumatakbo sa hatinggabi sa ika-1 ng bawat buwan, hindi sa Enero 1, ay nangangailangan ng pagsasanay. Ang parser sa itaas ay ginagawang sampung-segundong sanity check ang pagsasanay na iyon — i-paste ang expression, basahin ang Ingles, i-scan ang susunod na sampung oras ng pagpapatakbo sa iyong lokal na zone, at ipadala ang YAML na alam na ang cron line ay talagang ginagawa kung ano ang sinabi ng commit message.

Ano ang pagkakaiba sa pagitan ng 5-field at 6-field na cron?

Ang limang-field na cron ay ang klasikong Unix grammar na may resolusyon na isang minuto. Ang anim na field na cron ay nagdaragdag ng nangunguna na column ng segundo para sa sub-minute na pag-iskedyul — ginagamit ng Quartz at Spring's @Scheduled. Gumagamit din ang AWS EventBridge ng anim na field, ngunit ang karagdagang column nito ay isang trailing na taon, hindi segundo.

Ano ang ibig sabihin ng @hourly, @daily, at @weekly?

Mga palayaw ng Vixie-cron na ipinakilala noong 1987. Ang @hourly = 0 * * * *, @daily = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly = 0 0 1 1 *. Ang @reboot ay nagpapatakbo nang isang beses sa boot. Tinatanggihan ng GitHub Actions at EventBridge ang mga alias na ito.

Ang Linggo ba ay araw 0 o araw 7 sa cron?

Pareho, sa classic na Vixie cron — ang 0 at 7 ay tinatanggap para mabasa ang mga hanay tulad ng 5-7 nang natural bilang Biyernes-hanggang-Linggo. Ang Lunes ay laging 1, ang Sabado ay laging 6. Gumagamit ang Quartz at AWS EventBridge ng ibang konbensyon: 1-7 na may Linggo bilang 1. Suriin ang docs ng platform bago mag-assume.

Paano hinahawakan ng cron ang daylight saving time?

Depende sa timezone ng engine. Sa UTC (ang default sa EventBridge, Kubernetes, at GitHub Actions) ang DST ay hindi umiiral. Sa isang lokal na DST zone, ang classic na Vixie cron ay nilalaktawan ang mga trabaho sa panahon ng spring-forward gap at pinapatakbo ang mga ito nang dalawang beses sa panahon ng fall-back; ang mga timer ng systemd ay nagpapatakbo nang eksaktong isang beses.