Your CronJob says nine o'clock, but it fires late. The daily-report job, written for a 9 AM Berlin run, shows up at 10 in winter and 11 in summer. The chart shows that gap. Because the delay changes with the season, this isn't random drift. Something is shifting the clock.

Here's the cause. With no timeZone set, kube-controller-manager reads the schedule in its own clock, which is often UTC, especially on managed clusters. So 9 AM means 09:00 UTC. On the left, the Berlin clock reads 10:00 in winter. On the right, the controller clock reads 09:00. Same instant, two zones.

The controller's 09:00 UTC never moves. What changes is Berlin's offset. In winter, Central European Time is UTC plus one, so the job lands at 10:00 Berlin. In summer, daylight saving makes it UTC plus two, so the same run lands at 11:00. The local hour jumps twice a year.

Here's the manifest as the developer wrote it. Look at the schedule line, zero nine, star, star, star. It says nine o'clock, but nothing in this file says whose nine o'clock. There's no timeZone field, so the controller's default zone quietly decides, and on many clusters that's UTC.

The fix is one field, spec.timeZone, set to an IANA zone name like Europe/Berlin. Now 0 9 * * * means nine in Berlin, year-round. It's stable since Kubernetes v1.27. Don't put TZ or CRON_TZ inside the schedule string. Kubernetes rejects those prefixes.

These are two separate clocks. On the left, spec.timeZone tells the CronJob controller when to start the Job. That's all it does. On the right, the container has its own zone, which shapes log timestamps and any time logic in your app. That's usually UTC, unless the image or a TZ environment variable changes it.

A local zone brings daylight saving edge cases with it. When clocks spring forward in Berlin, 02:30 never happens, so a job scheduled there can be skipped. When they fall back, that hour happens twice, so behavior can surprise you. Avoid scheduling inside the transition window.

To verify the fix, run kubectl get cronjob and check the TIMEZONE column. It should say Europe/Berlin. Then read lastScheduleTime. Kubernetes stores it in UTC, so 08:00 with a Z is 09:00 in Berlin during winter. That confirms the schedule follows local time. This output is illustrative.

Choose UTC for system tasks that need even spacing, since it never shifts with DST. Choose local time for human-facing jobs like the Berlin report. The cost is edge cases, so keep local schedules out of the 02:00 to 03:00 transition window.

A cron schedule is meaningless without its clock. Kubernetes uses the controller's zone unless spec.timeZone names an IANA zone. So decide deliberately between UTC and local time, set spec.timeZone yourself, and don't trust the default.