2 ms·
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
by latchkey 1y ago
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.
- lxgr 1y agoThat 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.
- ipaddr 1y agoIf you want an email of the report to send out at 9am locally. Generate before and send to everyone based on timezone.
- kjehjrktlhl 1y agoYou 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.
- lxgr 1y agoI 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.
- lenzm 1y agoYes, that's exactly what I want. Everything shifts with dst - business processes, people's working hours, ach windows, ...
- gruez 1y ago> 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?
- latchkey 1y agoThe 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.