Avoid 2:00 and 3:00 am cron jobs (2013)

Posted by pera 10/27/2025

Avoid 2:00 and 3:00 am cron jobs (2013)(www.endpointdev.com)

341 points | 369 commentspage 3

magarnicle 10/27/2025|

The problem is not so much which timezone you pick, the problem is that cron uses 'naive' datetimes. If the timezone is explicit then you don't have duplicate hours because one is 02:00 and one is 02:00DST.

And then you can translate that time to any other timezone with ease, knowing that you are referencing a specific hour in physical time that only ever happened once.

LeoPanthera 10/27/2025||

> knowing that you are referencing a specific hour in physical time that only ever happened once

"Falsehoods programmers believe about time"

This assumption can break with:

* Leap seconds

* Calendar and time zone changes

* (In exotic circumstances) Relativity

magarnicle 10/27/2025||

I'll give you leap seconds, but at least in Python historical timezone changes are recorded in the datetime library, so the timezone at any particular time in the past has the timezone offset that was active then.

magarnicle 10/27/2025||

Which is to say I wish cron had the TZ variable that Jenkins uses in it's scheduling system. And the H value to easily spread multiple jobs over the hour/day/month etc.

MayeulC 10/27/2025||

Not a crown job, but I configured my lights to turn on progressively at my scheduled wake up time, using Home Assistant.

I figured that scheduling lights to turn on at <0 AM + wake up time> was a good approach... We got a surprise early wake up last year, so I ended up changing the formula to <4 AM - 4 hours + wake-up time>.

atoav 10/27/2025||

If you want to avoid overlapping runs simply simply have the task check for the existence of a lockfile, if not create a lockfile containing the start timestamp, run the task and delete the lockfile at exit or error.

The timestamp gives you a chance to recognize stale/orphraned lock files in case of crashes based on their age.

tomkaos 10/27/2025||

I avoid cron job at this time for this reason and for many other random problem because 3:00 am seem to be often choose for a maintenance like automatic update, server reboot, database backup..

tclancy 10/27/2025|

Can be tricky: an old project had a job that ran every 15 minutes to poll data from a popular smart thermostat company. I always knew when DST was starting or ending because that job would throw an error email at 2/3am on those days.

tokyovigilante 11/1/2025||

Whatever argument you may have against DST, “my cron jobs won’t run twice a year!” is not a strong one.

skopje 10/27/2025||

UTC also solves plotting daily time plots in zones with time changes (twice a year when the plots make no sense). But there still isn't no good fix for leap year plots!

bobmcnamara 10/27/2025|

Just use TAI?

sharts 10/29/2025||

Why run crons at that time anyway? It seems the most logical times for things are going to be midnight or beginning/end of business day.

cadamsdotcom 10/27/2025||

Great to read about something that's a solved problem now. It's been a very long time since I used a server that wasn't set to UTC.

bobmcnamara 10/27/2025|

I've seen this same problem under UTC. Gotta use TAI

nubinetwork 10/28/2025||

Doesn't systemd timers fix this? AFAIK, a job set to run once a day shouldn't run a second time because the time rolled back.

cmiles8 10/27/2025|

Or just use UTC and stop using timezones in code. I get it’s not that simple for some use cases but UTC exists for a reason.

bobmcnamara 10/27/2025|

Use TAI.

UTC has most of the same wacky timezone problems, just less often.

ericpauley 10/28/2025||

You’re signing up for a world of pain in the real world, where every other system is UTC. Just use UT1 or smear the leap second if you really can’t stand the risk.

bobmcnamara 10/28/2025||

Approaching one second per second, is that so much to ask?

Unless standardization has improved, how+when the second is smeared(if at all) means timestamps from the same system aren't usefully subtractable without communicating a separate time skew calendar.

That said, time is a big topic, and everything has different requirements but migrating to TAI and treating UTC as yet another human readable time zone has solved more (admittedly application specific) problems than it created.

More comments...