[ta1243]

If I want a report of what happened at a specific time I need that report at local time

I get a daily status report of various things from our 24 hour operational management team which runs at 8am UK time every day. That means last week it ran at 0700UTC and this week at 0800UTC

This is built around operational events, shift changes, etc.

I've got another system which is in operation in Sydney from 0630 to 1630 local time, this means that maintence windows which overlap with UK shift patterns depend on the week but mean the system is operating 2130-0730 UK time at some times, 2030-0630 UK at others, and 1930-0530 at others.

UTC is not "the answer". Sometimes you want things running at a UTC time, sometimes you want them running at local time.

I have a regular meeting at 10am London time on Tuesday and Thursday. That can't be stored in UTC as it varies depending on the time of the year. It has to have the timezone stored and actioned.

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

[baq]

I agree with most everything except:

> If I want a report of what happened at a specific time I need that report at local time

this is hard when a particular hour can happen twice in a day right?

[ta1243]

It certainly is, but that's a business question, not a technical question

If the business requires it to run at 01:30 and there are two per day, or zero per day, then the business rules needs to define what happens. You can't solve this by running it at UTC.

[baq]

Technically correct, but the business needs to be aware and a solution needs to be proposed beforehand IME. UTC is such a solution, imperfect, but usually workable. Business rules are sometimes unexpectedly elastic when confronted with a particularly explosive mix of logic and legislation.