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.
> 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
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.
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.