The reporting job should be run from a server on UTC and on UTC time. The report itself can convert to whatever is local time. This is exactly what I said above.
The reporting job should be run from a server on UTC and on UTC time. The report itself can convert to whatever is local time. This is exactly what I said above.
That works if all your consumers of the report are indifferent to it arriving at a different time half of the year.
All of yours might well be, but you can't generalize that assumption to every domain and scenario.
If you want an email of the report to send out at 9am locally. Generate before and send to everyone based on timezone.
> Generate before and send to everyone based on timezone.
How are you going to do this? Clearly cron (with timezone set to UTC) doesn't work for this so you'll need another system. In that case why not have that multi-time zone scheduling system run your script?
You don’t want a report to include 25h or 23h twice a year just to be able to send it at some distinct local time.
I absolutely want some daily business reports to cover 25 hours on one day of the year and 23 on another, since that's how long a calendar day is in local time in every place that has DST shifts.
Yes, that's exactly what I want. Everything shifts with dst - business processes, people's working hours, ach windows, ...
The report can run at whatever time you want it to run at. But this solution solves the issue of the report running 2x or not at all.