[artisinal]

That is why you run your jobs on GMT/UTC and not display time.

[reedf1]

I guess that is what I'm trying to show in the above example. You could technically shift your UTC jobs by running your own NTP server and desyncing it from UTC by the offset you want. It would work, but it would be nightmare fuel. And possibly this is an even better example of what DST is doing.

[kuboble]

Well, it's not that obvious.

Some jobs should run every day at 8 am (e.g. torn on the temporary speed limit on front of the school), vs tasks that should actually run every 24h (e.g. feed the bacteria in exact time intervals)

[edoceo]

The jobs need to run at midnight, local time. Which shifts from UTC. How to handle?

[defrost]

Why does it need to run at that time?

* If it's being run to scrap data from a source that's available at some time, adjust the job if the source changes its time.

* If it's being run "when its dark and no one is around" then it'll run at some part of the dark bit regardless of DST changes.

[Retric]

Sometimes you minimize downtime by running something while some other system you don’t control is down.

[edoceo]

Billing and regulatory compliance

[defrost]

In that specific case, handle the job time by making it compliant.

The reason I posed a leading rhetorical question was that not all cron jobs are equal and how each is handled depends on the nature of each.

[ssl-3]

Use UTC, and stop faffing about with changing localtime twice every year so the offset is a constant?