One Clock for Every Workspace
The application clock is one value for the whole installation, and the deployed value is Nairobi. Report schedules and workflow calendars each carry their own timezone and honour it; every record stamped anywhere else in the product does not, because there is one clock and it is not a column.
A sale rung up at half past midnight in Lagos is stamped with a date that has not started there yet.
This is not a bug so much as a shape, and the shape is worth understanding before it surprises you. The application has one clock. It is set once, for the whole installation, from a single environment value — and the deployed value is Africa/Nairobi. Every timestamp the product writes without being told otherwise resolves against that clock: the moment a receipt was issued, the moment a ticket was opened, the moment a movement was posted, the moment a payslip was generated.
For most readers of this post, nothing follows from it
Nairobi is UTC+3 and observes no daylight saving. Kampala, Dar es Salaam, Kigali, Addis Ababa and Antananarivo are the same offset, all year. If your workspace is in any of them, the application clock is your clock, and everything below is a description of something you will never see. It is the workspace that reaches across an offset that needs to read on.
Three clocks, and only two of them move
There are three separate questions a system can ask about time, and this product answers them from two different places.
Which clock answers which question
| Question | Per schedule | Per workspace | Per user |
|---|---|---|---|
| When should this report be sent? | Yes | No | No |
| When is this workflow allowed to notify? | Yes | No | No |
| What date is stamped on this record? | No | No | No |
| What date do I see on screen? | No | No | No |
Built and maintained Configurable by you, not maintained by us Not built
The bottom two rows are answered by the installation clock, which is the same value for every workspace and every person in it. The top two are answered by a column on the schedule, which defaults to UTC and can be set to anything.
The scheduling half is properly built. A report schedule carries its own timezone, converts the current instant into it before working out the next run, and converts back afterwards — so a seven-o'clock report genuinely arrives at seven in the morning wherever seven in the morning is. Workflow business calendars and workflow notification preferences each carry the same column for the same reason.
The record half is not. There is no timezone column on a workspace and none on a person, so there is nothing for a record to be stamped against except the installation's own clock.
The system knows what time to send you a report. It does not know what time it is where you are.
What an offset actually costs you
The size of the problem is the size of the offset, and it only bites near a boundary. Here is the same instant, read four ways.
| Where the work happened | Local time | Offset from Nairobi | Date stamped on the record |
|---|---|---|---|
| Nairobi, Kampala, Addis | Mon 23:40 | none | Monday — correct |
| Lagos, Abuja | Mon 21:40 | minus 2 | Monday — correct |
| Accra, Freetown | Mon 20:40 | minus 3 | Monday — correct |
| Lagos, Abuja | Mon 22:30 | minus 2 | Tuesday — a day early |
| Karachi, Islamabad | Tue 01:40 | plus 2 | Monday — a day late |
| Manila, Perth | Tue 04:40 | plus 5 | Monday — a day late |
Read the last three rows as the whole of the issue. An offset does not corrupt a timestamp — the instant recorded is the correct instant, and two records an hour apart are still an hour apart. What an offset moves is the date, and only for work done inside the offset's width of midnight. Two hours west of Nairobi, that is the last two hours of your evening. Five hours east, it is the first five hours of your morning, which is considerably worse because that is when a warehouse opens.
Where a moved date is felt
- A daily figure. Anything grouped by day cuts at Nairobi midnight, so an evening two hours west lands in tomorrow and an early shift five hours east lands in yesterday.
- A cut-off. A period that closes on the last day of the month closes at a moment that is not local midnight, and the last few hours of local trading fall the other side of it.
- A duration read by a person. An elapsed clock is unaffected — the arithmetic is instant to instant — but the two endpoints printed beside it are in a zone the reader is not in, so a correct duration is read against two odd-looking times.
- A reconciliation against something external. A bank feed, a till provider or a tax portal stamps in its own zone. Where that zone is neither yours nor Nairobi, you are matching across two offsets rather than one.
And one place it is genuinely not felt: sequence. Everything is stamped from the same clock, so ordering, ageing, response targets and every calculation that subtracts one stamp from another are all exactly right. This matters because it is the difference between a presentation problem and a data problem, and this is a presentation problem.
What to do about it now
-
Work out your offset once and write it down
Not per person, per workspace: hours from UTC+3, and whether your zone observes daylight saving. If the answer is zero, stop here — you have no offset and no exposure.
-
Set the timezone on every scheduled report
This one you control today, and the default is UTC rather than Nairobi, so an unset schedule is already three hours out from the rest of the system. Setting it costs nothing and is the single highest-value minute in this article.
-
Decide which daily figure you actually run the business on
Usually one or two — a takings figure, a movements count. Those are the ones where a moved date will be argued about. Everything else tolerates the boundary without anyone noticing.
-
Move that figure off midnight if you can
A weekly or monthly total absorbs a two-hour shift completely, because the boundary hours are a rounding error against a month. Where the daily figure is the one that matters, expect it to disagree with a locally-stamped source by the width of your offset and say so in the report note rather than reconciling it every time.
-
Read a stamped time as a stamp, not as a clock
The most common way this causes an argument is somebody reading 02:14 on a record and concluding a colleague was working at two in the morning. Tell your reviewers what zone they are reading before they draw a conclusion from it.
Do not change the installation clock to fix one workspace
It is one value for everyone on the installation. Moving it to suit a workspace in Lagos moves it for every workspace in Nairobi, and it also re-reads every historical timestamp against the new zone — so yesterday's records quietly acquire different dates than the ones already printed on reports people have kept. A per-workspace setting is the fix; the global one is not a dial to be turned.
How to ask any vendor about this
The reason this is worth a whole article is that almost no procurement checklist asks about it, and almost every hosted system has some version of it. The question that separates a real answer from a reassuring one is not "do you support timezones" — everybody says yes, because a scheduler is zone-aware. It is which of the three clocks is per-workspace.
What AWRA OpsHub does today
- A timezone on every scheduled report, honoured properly: the next run is computed in that zone and converted back, so a local send time stays local across the year.
- A timezone on workflow business calendars and on workflow notification preferences, so quiet hours and working windows are evaluated where the workflow lives.
- Instants stored consistently from a single clock, which makes every ordering, ageing, elapsed-time and response-target calculation in the product exactly correct regardless of where the work happened.
- A separate, deliberately incomplete registry of country operating contexts for the public site, which returns nothing rather than guessing an offset it does not know.
More we can add to your workspace
- A workspace timezone, set once at setup, that every stamped date and every daily boundary in a report is rendered against.
- A per-person display timezone, so a regional manager reads the same record in their own working day and a shared record still means one instant.
- A day boundary that follows the workspace, so a daily takings figure closes at local midnight rather than at the installation's.
- The zone shown beside a printed timestamp, which is the cheapest of these by a distance and removes most of the confusion on its own.
- A per-workspace financial period cut-off in local time, for the month-end that currently closes a few hours early or late.
Where we point you to a specialist
- We would decline to infer a workspace timezone from a browser, an IP address or a phone. A record's date would then depend on where the person happened to be standing, which turns a fixed fact into a travelling one — and the version of this that is wrong is much harder to detect than the version that is merely offset.
- Where a tax authority or a regulator specifies the timezone a filing is reckoned in, that specification wins over any workspace preference, and we will implement the statutory zone rather than offer a setting that appears to override it.
- Historical restamping is something we would talk you out of. Re-rendering past records against a newly chosen zone changes dates on documents your auditors and customers already hold, and a workspace setting should apply from the day it is set rather than reach backwards.
A workspace timezone plus a zone label beside printed timestamps is a contained, well-understood piece of work, and it removes the great majority of the confusion described here. If your operation spans an offset, it is the one to scope.
One column and one rendering rule
The scheduling side already proves the pattern works in this codebase — a zone on a record, honoured at the point of use. Extending it to the workspace is the same idea applied one level up.
A timezone on the workspace
Chosen at setup, defaulting to the installation's, and used wherever a stored instant becomes a date a person reads.
A local day boundary in reports
The half that changes figures rather than labels, and the half worth scoping carefully — a daily grouping that shifts is a daily grouping that has to be explained once to everyone who kept the old one.
A zone label on a printed time
Small, quick, and the one that stops the arguments even before the other two land.
We publish scope, not dates.
Scope a workspace timezoneFour questions for any system you are buying across an offset
Is the timezone set per workspace or per installation?
A good answer sounds like
Per workspace, here is the setting.
What ours actually is
Per installation, and the deployed value is Africa/Nairobi. Ask this first — a scheduler being zone-aware is a different answer to the same-sounding question.
What zone does a daily report cut at?
A good answer sounds like
The workspace's midnight, and here it is on the report.
What ours actually is
Nairobi midnight. If your offset is zero this is your midnight too.
Can I set the send time of a scheduled report in my own zone?
A good answer sounds like
Yes, per schedule.
What ours actually is
Yes, genuinely — and the default is UTC, so set it rather than assuming it.
If I change the timezone setting, what happens to last year's records?
A good answer sounds like
A clear answer either way, stated before you ask twice.
What ours actually is
A question we treat as a design boundary rather than an option, because a silent restamp changes documents people already hold.
Our take
For a workspace anywhere in East Africa this is a non-event, and saying otherwise to sound thorough would be dishonest — the installation clock is the local clock and the dates are simply right. For a workspace two hours west or five hours east, it is a real and permanent readability tax on a narrow band of hours around midnight, with no effect on ordering, durations or any calculation. The single action worth taking today is the smallest one: set the timezone on every scheduled report, because that default is UTC rather than Nairobi and it is the one clock you already control. After that, know your offset, know which daily figure you argue about, and read a stamp as a stamp.
Work out your offset before it works itself out on a report
It takes about a minute and it decides whether any of this applies to you. If your answer is zero hours, you can close this article and never think about it again — which is genuinely the most likely outcome and the reason the post says so in its second paragraph.
Talk through your zonesFrequently asked questions
Is my data wrong if my workspace is not in East Africa?
No. The instant recorded is the correct instant, and every calculation that subtracts one instant from another — ageing, response targets, elapsed time, ordering — is exactly right. What is offset is the date and time a person reads, and only for work done within the width of your offset of midnight. It is a presentation issue rather than a data one, which is why it can be fixed later without anything needing to be recomputed.
What timezone is the installation actually set to?
Africa/Nairobi, which is UTC+3 and observes no daylight saving. The absence of daylight saving is worth knowing on its own, because it means your offset from the system is a single number all year rather than two numbers that swap in spring and autumn.
Can I set a different timezone for my workspace?
Not today. There is no timezone column on a workspace or on a person, so there is nowhere for a preference to be stored. Report schedules and workflow calendars each carry their own timezone and honour it properly, which is the part of the problem most people notice first and the part that is already solved.
Why does a scheduled report default to UTC rather than to the application clock?
Because a schedule column with no value has to default to something, and UTC is the conventional neutral choice. The practical consequence is worth acting on: an unset schedule fires three hours away from the clock everything else in the product uses, so setting the zone explicitly on each schedule is worth doing even in Nairobi.
Does daylight saving affect any of this?
Not on the system side, since the application clock does not observe it. It affects you if your own zone does, because your offset from the system then changes twice a year and a rule you wrote in January is two hours wrong in July. Zones in Europe, North America, Australia and parts of the Middle East are the ones to watch; almost all of Africa and most of Asia are stable year-round.
How do I reconcile a daily figure against a locally-stamped source?
Expect them to disagree by the volume of work done inside your offset of midnight, and confirm that is the whole difference rather than reconciling it line by line each time. Where the two must match exactly, move to a weekly or monthly comparison, which absorbs the boundary completely because the shifted hours are the same hours at both ends of the period.
