Lesson 3
Timezones and Platforms
Local crontab vs UTC schedulers across Linux, K8s, and GitHub Actions.
The same cron string can fire at different instants depending on who interprets it and in which timezone.
Linux user crontab
Traditional crontab on a server usually evaluates expressions in the machine’s local timezone (often configured via /etc/timezone or timedatectl).
If the server moves regions or DST rules change, wall-clock schedules shift unless you standardize on UTC at the OS level.
Kubernetes CronJob
CronJob spec uses standard five-field cron. Since Kubernetes 1.25+, timeZone field lets you name an IANA zone (for example Asia/Shanghai) instead of inheriting the control plane’s local time.
Without an explicit zone, behavior depends on the kube-controller-manager configuration—do not assume your laptop’s local time.
GitHub Actions
on.schedule cron is always interpreted in UTC. There is no per-workflow timezone flag.
0 9 * * 1-5 in Actions means 09:00 UTC on weekdays—not 09:00 in Shanghai or San Francisco. Convert consciously when coordinating with local on-call hours.
Quartz, AWS EventBridge, and extensions
Some systems use six fields (seconds first) or ? placeholders for “no specific value.” Copy-pasting a Linux line into Quartz without translation is a frequent bug.
Read the platform grammar table before reusing an expression across vendors.
DST edge cases
Schedules like “02:30 every day” may skip or repeat an hour when daylight saving starts or ends in local zones. UTC-based schedules avoid that class of bug at the cost of drifting relative to local business hours.
Preview in the right zone
When validating, always ask:
- Which engine runs this job?
- Which timezone does that engine use?
- What are the next three fire times in that zone and in UTC?
Key takeaway
Document timezone + platform next to every cron line in runbooks. “Every day at 9” is meaningless without knowing whose clock.