Belajar Cron Job - Timezone & DST Handling

#Pendahuluan

Di episode 15 kita memindahkan cron ke cluster Kubernetes. Sekarang kembali ke dasar yang sering diabaikan: waktu. Cron mencocokkan field waktu dengan jam sistem — dan jika jam sistem di zona waktu yang salah, atau zona waktu itu punya aturan Daylight Saving Time (DST), semua jadwal "benar" pun bisa berjalan di jam yang keliru.

Indonesia tidak menerapkan DST, tetapi banyak infrastruktur yang kalian kelola bisa terhubung dengan region yang menerapkannya (misal Eropa atau Amerika Utara). Episode ini membahas bagaimana cron menangani timezone dan DST, serta kebijakan yang menghindari masalah ini selamanya.

#Timezone di Crontab

#Timezone Default: Waktu Lokal Host

Cron secara default membaca jam waktu lokal host — dari localtime sistem. Inilah kenapa satu server di Jakarta dan satu di New York mengeksekusi 0 2 * * * pada waktu lokal masing-masing.

Cek timezone host:

Cek timezone host

timedatectl
date

#CRON_TZ: Timezone Per-Crontab

Cronie menyediakan CRON_TZ untuk mengatur zona waktu khusus crontab — tanpa mengubah zona host:

Crontab dengan CRON_TZ

CRON_TZ=Asia/Jakarta
 
30 2 * * * /usr/local/bin/backup.sh

Dengan CRON_TZ=Asia/Jakarta, jadwal dievaluasi di waktu Jakarta, apa pun zona host. Ini penting untuk job yang harus sinkron dengan waktu bisnis lokal — misal laporan yang harus jadi sebelum kantor buka pukul 07.00 WIB.

Report 06.30 WIB

CRON_TZ=Asia/Jakarta
SHELL=/bin/bash
 
30 6 * * 1-5 /usr/local/bin/morning-report.sh

Note

CRON_TZ memakai database tzdata (IANA) — nama zona seperti Asia/Jakarta, Asia/Makassar, atau Etc/UTC. Nama ini harus valid; cek dengan timedatectl list-timezones | grep Asia. Nama zona lebih andal daripada offset seperti +7 karena mengikuti aturan DST secara otomatis.

#DST: Ketika Jam Melompat

#Bagaimana DST Mempengaruhi Job

Di zona waktu dengan DST, jam maju satu jam di musim semi ("spring forward") dan mundur di musim gugur ("fall back"). Dampaknya pada cron:

Spring forward: jam 02.00-03.00 tidak ada. Job 30 2 * * * tidak berjalan hari itu.
Fall back: jam 01.00-02.00 terjadi dua kali. Job di rentang itu bisa berjalan dua kali.

Keduanya berpotensi merusak: job yang lewat, dan job yang dobel.

#Mengapa Indonesia Bisa Terkena

Bahkan server di Indonesia bisa terkena dampak ini jika:

CRON_TZ menunjuk zona ber-DST, atau
host di-set ke zona ber-DST karena salah konfigurasi, atau
kalian menjadwalkan terhadap waktu region lain yang ber-DST.

#Best Practice: UTC untuk Infrastruktur

#Set Host ke UTC

Kebijakan yang paling banyak dipakai di industri: seluruh infrastruktur memakai UTC, dan konversi ke zona lokal dilakukan di lapisan presentasi (aplikasi), bukan di penjadwalan.

Set timezone host ke UTC

sudo timedatectl set-timezone UTC
timedatectl

Keuntungannya:

Tidak ada DST di UTC — jadwal tidak pernah lompat.
Log dari banyak host di banyak region bisa dibandingkan tanpa konversi.
Koordinasi antar tim/region menjadi satu bahasa: UTC.

#Sediakan Job di Jam Stabil

Untuk job yang harus berjalan di jam lokal tertentu sementara host memakai UTC, ekspresikan dalam UTC:

Backup 02.30 WIB = 19.30 UTC

30 19 * * * /usr/local/bin/backup.sh

Atau kombinasikan dengan CRON_TZ jika lebih jelas secara bisnis:

Dengan CRON_TZ untuk kejelasan bisnis

CRON_TZ=Asia/Jakarta
 
30 2 * * * /usr/local/bin/backup.sh

Tip

Pilih salah satu pola dan konsisten. Campur UTC dan CRON_TZ tanpa dokumentasi adalah sumber kebingungan terbesar. Rekomendasi: host dan log dalam UTC, CRON_TZ hanya untuk job yang memang mengikuti waktu bisnis lokal, dan selalu tulis komentar di crontab menjelaskan zona yang dipakai.

#Ringkasan Kebijakan Waktu

Situasi	Praktik
Infrastruktur umum	Host UTC, log UTC
Job mengikuti waktu bisnis lokal	`CRON_TZ=Asia/Jakarta`
Region ber-DST	Hindari jam yang lompat; gunakan UTC
Job harian sensitif	Jadwalkan di jam stabil, hindari jam 02.00 di zona DST
Koordinasi tim	Satu bahasa: UTC

#Penutup

Inti yang harus dibawa pulang:

Cron memakai waktu lokal host; CRON_TZ mengatur zona per crontab.
DST membuat job bisa tidak jalan (spring forward) atau jalan dua kali (fall back).
Set seluruh infrastruktur ke UTC untuk stabilitas dan keterbandingan log.
Gunakan CRON_TZ hanya untuk job yang mengikuti waktu bisnis lokal.
Dokumentasikan zona waktu tiap jadwal di komentar crontab.

Di episode 17 selanjutnya kita akan membahas Cronie 1.7.x dan fitur terbarunya — perbaikan MAILFROM, opsi -n untuk menunggu job selesai, anacron terintegrasi, dan perbandingan lengkap cronie vs vixie-cron vs systemd timers vs at!