[latchkey]

You can tell the job when to run in UTC time and change that time depending on what the current DST rules are.

But if the job is set to run in UK time and the system clock jumps around because of TZ changes, it will run twice or not at all.

Having a stable zero based time that doesn't move around by external forces that you can't control is "the answer."

[ta1243]

So I have to manually update the job

How about I use some form of library to do it. I tell it I want to run at 0800 London time, and it runs at 0800 London time

If I tell it I want to run at 0130 London time (or 0330 Athens time) I still have a problem -- do I run it twice when the clocks go back, do I skip it when clocks go forward?

But that's a business logic problem, and defining it as UTC and having another job to update the time twice a year doesn't actually solve the question of "what do I do at this point".

[latchkey]

You don't have any choice in the matter. If you control the time you want the jobs to run externally from the server, then you can have control over it. Otherwise, you're getting jobs that run 2x or not at all.

[ta1243]

No matter where you run the job from, you run it in the required timezone, not UTC, and you still have the issue with what to do with the change in the local timezone.

This isn't a problem that can be solved with a single technical solution.

[ipaddr]

Generate earlier and send to various timezones when needed.