That's true if you need to clean up temporary files every night or make a backup.

But what if your cronjob has an effect in the physical world, locally? E.g. open the parking gates every morning.

The world is inherently messy :-)

That sort of thing would be best handled by your own user's crontab, so would naturally inherit that user's TZ.

If you must run it as root, you can specify a CRON_TZ variable on a per-file basis, which will override the default.

Well assuming that the gates don't move timezones. But obviously jobs that need to run for a given timezone should be configured to run in that timezone.

Unless the gates need to open at 2:30am and in the case of daylight savings time that hour is skipped.

Not if that cron file (you can have multiple cron files per user/system) is configured to run in the local timezone.

But then wouldn't the job run twice when time "falls back"?

no, it would run either twice at the "same time" as it is read out, but obviously 60 minutes apart time duration wise; but this can't be helped as this time "existed" twice in that time zone. Or conversely in spring that time wouldn't happen at all, but the cron job will still run 60 minutes apart time duration wise. But this is the downside of local time, just make sure if you want to open a door at 01:30 local time that that is what you really want, because the unintended consequences could be a bit strange.

> That's true if you need to clean up temporary files every night or make a backup.

Making a backup is usually reserved for the quietest hours of the morning, so that it does not compete as much for resources with the normal operation of the system; in my experience, the quietest hour is usually around 4:00 local time.

Tangentially, Debian’s vixie-cron did / does handle DST, but it did not handle TZ changes [0], as I discovered.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019716