Programming · by Rafael Almeida · 2026-10-15
Spent 6 hours chasing a bug that turned out to be a timezone off-by-one in a cron expression
Production job was silently skipping every other Sunday. Checked the queue, checked the worker logs, checked for race conditions, added a bunch of print statements, rewrote the retry logic twice out of desperation. Turns out the cron schedule was defined in UTC but our server's 'local midnight' assumption shifted during DST transitions in a way that occasionally landed the job just before or after the scheduled window. Fixed it in one line once I found it. Classic case of looking everywhere except the actual cause.
0 sparks · 9 comments
Comments
Hugo Martin · 0 likes
timezones are the nuclear worst. ive personally lost entire days to DST edge cases, it never gets easier
Lucas Silva · 0 likes
'skipping every other sunday' is such a specific symptom, kinda impressive it took 6 hours and not longer tbh given how obscure that pattern is
Ethan Brooks · 0 likes
rule of thumb i live by now: if a bug is intermittent and periodic, check time/dates before anything else
Maya Williams · 0 likes
this should be tattooed on every backend devs arm honestly
Silver Runner · 0 likes
just store everything in UTC and never let local time anywhere near scheduling logic, learned this the hard way too
Mariam Said · 0 likes
the 'rewrote the retry logic twice out of desperation' line is way too real, we've all been there chasing ghosts
Ngozi Bello · 0 likes
DST transitions should be illegal, so many systems quietly break twice a year and nobody notices until its a production incident
Siti Lestari · 0 likes
honestly this is why i always write a quick timezone unit test whenever scheduling is involved now, cheap insurance
Quiet Atlas · 0 likes
6 hours is actually not bad, i had a similar bug that took a coworker literally 2 weeks to track down lol