Time Zone

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.

Stored Against Displayed

A date has two aspects: the moment it records, and how that moment is shown. Confusing them causes most time-related bugs.

Where to find it

Architect Panel → Configuration:

• Site Settings — the option groups, grouped by subject

The distinction

A timestamp records a moment. The time zone decides how that moment is written down for a reader. The same moment is 15:00 in one place and 10:00 in another, and neither is more correct.

So changing the time zone does not move any record. It changes what every record appears to say.

Which is why reports can disagree

A report run before a zone change and one run after will differ at the boundaries — records near midnight move to the adjacent day. Nothing was altered; the day boundary was.

Dates without times are different

A date of birth, an invoice date, a contract date. These are dates, not moments, and they should not shift with a time zone.

Treating a plain date as a timestamp is how a date of birth becomes a day earlier for some users, and it is a mistake that reaches production regularly.

Data from elsewhere carries its own assumptions

An import, an integration, a file from another system. Each has a zone, stated or assumed, and an import that assumes the wrong one is wrong by a fixed number of hours across every row.

Establish the source’s zone before importing rather than after somebody notices.

Check the day boundaries

Records created just after midnight and just before it are where zone errors show. If your daily counts are consistently slightly off, that is where to look.

Say which zone a report is in

On the report. A figure for "yesterday" is meaningless to somebody in another country without knowing whose yesterday, and it takes four words to say.

Be careful with exports

An exported date read by another system carries an assumption about its zone. Where the receiving system matters, export in an unambiguous format that states the offset rather than a local time somebody has to guess about.

Test around midnight

Create a record just before and just after midnight and check where each appears in daily reporting. That single test finds most day-boundary errors, and it can be done by setting the times deliberately rather than staying up.

Worked example

An organisation found its daily figures consistently a few records out. Records created late in the evening were falling into the next day because an import was assuming a different zone from the installation. Fixing the import’s assumption resolved it.

Recommendations

• A zone change moves nothing — it changes display.
• Plain dates are not moments — do not shift them.
• Establish an import’s zone before importing.
• State the zone on reports and test around midnight.