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.