DST is such a dumb mechanism anyway

just use UTC

2-3am is bad due to DST but there is another reason to also avoid 3-5am or so

around 3am is the time where "in average" human attention is the worst as its where "in average" their most relevant deep sleep phases are

now I guess the average over HN readers has a good chance to be somewhat later

but either way if the job goes wrong and triggers alarms 2-5am it very bad for the the health and sleep rithm of whoever needs to fix it and the most likely time they make mistakes

it sadly is also the time where non-international interruptions are least likely to matter

if you are an international company having international teams can be an solution

and if you are a very small team adopting job times to an overlap of low usage and your admins sleep habits can be an option

but if you need to pick a generic time and don't provide for logistics or other "start work at 4/5am" companies probably 5-6am is a better time to run your batch jobs

anyway just some random thoughts

It depends on tz. 4 am in some countries too

I have a job that deliberately runs at 2am and 3am... to update the time in a bunch of really old PLCs for DST. And check that every other device on my telemetry network has correctly updated its time.

bruh, just use UTC

Here's my radical time idea: instead of keeping the same schedule year round, we just incrementally chop parts of the day off (we just put that time in a "bucket" and pretend it doesn't exist). Then at the summer equinox we empty the time bucket into a 6 day bender of a party. /s

This isn't a problem with actual cron and crontab. It is a problem with the systemd-timers shim "crontab" which doesn't work the same in many corner cases and often has weird bugs.