One Place That Knows What Time It Is
A report schedule in this product carries its own timezone and computes its next run in it. The deadline engine three modules away has no timezone at all. The capability exists, once, in the place where getting it wrong matters least.
When a system cannot do something, the useful question is whether it cannot or whether it simply does not. The two look identical from the outside and they cost completely different amounts to change.
The place that knows
A scheduled report carries a timezone of its own. When the system works out when it should next run, it converts into that zone, applies the cadence and the time of day, and converts back.
That is correct per-record timezone handling. A daily report timed for eight in the morning arrives at eight in the morning where the person reading it is, not at eight in the morning where the servers are — and two schedules on one system can legitimately disagree about when the day starts.
The place that does not
The support deadline engine. Business hours are a start time and an end time held on the organisation, with no zone attached, interpreted in the single timezone the application runs in.
So a support desk cannot express that its Dubai team works one set of hours and its team elsewhere works another. A report schedule can express exactly that, about itself, today.
Which parts of this product carry a timezone
| Where | Has its own zone | Uses the application zone |
|---|---|---|
| Report schedule next-run calculation | Yes | No |
| Support deadline arithmetic | No | Yes |
| Business hours start and end | No | Yes |
| Working week and holidays | No | Yes |
| Scheduled scans and reminders | No | Yes |
Built and maintained Configurable by you, not maintained by us Not built
One row out of five. That is what makes this a decision that was made once rather than a limitation of the design.
The hard part of timezone handling is deciding to store one. Everything after that is a library call, and this product has already made that decision — in one table.
Why it landed there and not elsewhere
Almost certainly because a scheduled report has an obvious, immediate, visible failure: it arrives at three in the morning and somebody complains the next day. The feedback is fast and the fix is local to one model.
A deadline computed in the wrong zone has no such symptom. It produces a due time that is a few hours off, on a ticket that is probably answered well within it, and the error surfaces only in an argument about a breach months later. Nobody complains, so nobody fixes it.
That is the general rule and it is worth carrying: the parts of a system that get timezone handling are the parts where getting it wrong is annoying, not the parts where getting it wrong is expensive.
Our position
Set your organisation to the timezone of the place the work actually happens, and use the per-schedule timezone deliberately for reports going to people elsewhere — it works and it is the one lever available. For support deadlines across zones, use the elapsed clock rather than business hours, because an elapsed promise cannot be wrong about a working day it never claimed to know.
What AWRA OpsHub does today
- A timezone on every report schedule, consumed when computing the next run and converted back for storage.
- A configurable working week per organisation, including weekends that are not Saturday and Sunday.
- Business day start and end times per organisation.
- A per-category support clock — elapsed wall-clock, or the organisation's working hours.
- A single working-calendar service resolving leave, workflow due dates and the business-hours clock consistently.
What it does not do
- Any timezone in the support deadline arithmetic.
- Any timezone on business hours, the working week or the holiday list.
- More than one business-hours window per organisation.
- A timezone per user, per branch or per customer anywhere.
- Any timezone on the scheduled scans and reminders — they run in the application zone.
Not ours, by choice
- One application timezone is correct for the majority of organisations using this product, and the constraint only bites across zones. The point of this page is that the constraint is a choice rather than an architecture, evidenced by the one place that made the other choice.
- The per-schedule timezone is genuinely well implemented and we would point at it as the model for how the rest should work.
- Nothing here is Emirati, Saudi or Qatari. The Gulf is here because regional headquarters covering several countries and time zones are an ordinary shape of business there.
Two, and the pattern is already in the codebase
A per-record timezone is not a research problem here. It exists, it works, and it is one model away from the places that need it more.
A timezone on the working calendar
The same column, on the settings that carry business hours and the working week — so a business day means a business day somewhere specific. This is the smaller half and it makes the existing business-hours clock honest rather than approximately right.
Calendars per team, each with its own zone
The larger version, and the one a regional operation actually needs: a support rota in one country and a back office in another, each with its own hours, holidays and zone, with a ticket category naming which applies. The mechanism for per-purpose calendars already exists in the code with no way to create one, so part of this is wiring rather than design.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product.
Talk to us about multi-region operationsFour questions about time in any system
Which records carry their own timezone?
A good answer sounds like
A list, and they know it.
What it actually means
Ours is one: the report schedule. The answer is rarely "all of them" and is often "none".
What timezone is a deadline computed in?
A good answer sounds like
A specific one.
What it actually means
If the answer is "the user's", ask to see the column. It is usually the server's.
Can two teams have different working hours?
A good answer sounds like
Yes, per calendar.
What it actually means
The requirement that separates a single-site product from a regional one, and most products fail it.
When a schedule and a deadline disagree, which is right?
A good answer sounds like
They cannot disagree.
What it actually means
Ours can, because only one of them has a zone. That is worth knowing before you reconcile them.
Ask where the zone is stored
Not what timezone the system is in — which records carry one. The answer tells you immediately whether a product was built for one place or several.
Talk about regional operationsFrequently asked questions
Can I set a different timezone per report schedule?
Yes, and it is honoured properly — the next run is computed in that zone. It is the one place in the product where per-record time works the way people assume it works everywhere.
Does the application timezone affect stored timestamps?
It is the zone the application interprets and displays in, so it is a deployment-level decision rather than a per-user preference. Changing it moves every business-hours deadline at once, which is why it is worth setting to your operating centre from the start.
Is this hard to fix?
The pattern already exists in this codebase, which is the whole argument of the page — the work is applying a solved problem to more tables rather than solving it. What needs care is deciding what a calendar belongs to, and that is a product question rather than a technical one.
