Setting the Time Zone
One setting names the installation’s time zone. A great deal depends on it.
Where to find it
Architect Panel → Configuration:
- Site Settings — the option groups, grouped by subject
Architect Panel → Data:
- Business Hours Calendars — per-team hours, which carry their own zone
Use a named zone, not an offset
The setting takes a named zone — a region and a city — rather than a number of hours. That matters because a named zone knows about daylight saving and an offset does not.
An installation set to a fixed offset is correct for half the year and an hour wrong for the other half, and the wrongness arrives overnight without anybody changing anything.
Choose the zone your organisation works in
Not where the server is. The server may be anywhere and may move; your working day does not.
What depends on it
- Every displayed date and time.
- Scheduled tasks — a job set for six in the morning runs at six in this zone.
- Due dates and deadlines, and therefore whether something is late.
- Reports grouped by day, and therefore which day a record counts in.
- Business hours calculations, in combination with each calendar’s own zone.
Set it before anything else
Because changing it later changes how every existing date is displayed. Records do not move, but their apparent times do, and reports produced before and after will not agree.
Daylight saving produces two real problems
- An hour that happens twice in autumn — a time that is ambiguous.
- An hour that does not exist in spring — a scheduled job set for that hour.
Both are rare and both are worth knowing about when something odd happens twice a year.
International operation needs more
One installation zone does not serve users in several countries well. Business hours calendars carry their own zones, which covers service levels; user-facing display is the harder part and needs deliberate thought before you open a second region.
Check it after installation
Look at a record you have just created and confirm its timestamp says what you expect. That takes ten seconds and catches a default left in place.
Check scheduled tasks after any change
They are the thing that silently moves. A nightly job that ran at two now runs at one or three, which matters if it depends on something else finishing first.
Worked example
An organisation set its zone to its own working region at installation and confirmed by creating a record and reading its timestamp. When a server moved to a different region, nothing changed for users because the zone was named rather than inherited.
Recommendations
- A named zone, never a fixed offset.
- Your working region, not the server’s.
- Set it before there is data.
- Re-check scheduled tasks after any change.