Midnight, but whose midnight
A medium Java puzzle in the scheduling and cron mistakes family. One line below contains a real bug. Try to spot it first, then read why it fails and how to fix it.
Highlighted: line 7. Play this one as a puzzle without the answer.
What is wrong
Without a zone attribute, Spring uses the server's default time zone. A container usually runs in UTC, so the job runs at 01:00 or 02:00 Berlin time and moves again when daylight saving changes.
The fix
How to avoid it next time
Always state the time zone for business schedules, and test around daylight-saving changes.
Want the background? Read @Scheduled jobs in the Java concepts library.
About scheduling and cron mistakes
Cron dialects differ in field count and meaning. Spring has six fields starting with seconds, Unix has five, Quartz needs a question mark in one day field, and time zones decide when midnight actually is.
In code review: Count the fields and check which dialect the framework expects. Confirm the time zone and what the day-of-week field numbers mean in that dialect.
More puzzles in this family
Frequently asked questions
What is the bug in "Midnight, but whose midnight"?
Without a zone attribute, Spring uses the server's default time zone. A container usually runs in UTC, so the job runs at 01:00 or 02:00 Berlin time and moves again when daylight saving changes. The faulty line is line 7: @Scheduled(cron = "0 0 0 * * *")
How do I fix it?
Replace it with: @Scheduled(cron = "0 0 0 * * *", zone = "Europe/Berlin"). Always state the time zone for business schedules, and test around daylight-saving changes.
How do I catch scheduling and cron mistakes in code review?
Count the fields and check which dialect the framework expects. Confirm the time zone and what the day-of-week field numbers mean in that dialect.
Is there a new puzzle every day?
Yes. The daily Spot the Bug puzzle picks one of these snippets for each UTC day, with the difficulty set by the weekday. Your streak is stored only in your browser.