The site time zone determines how dates and times are interpreted when stored, calculated and displayed. Get it right at install and you avoid endless “why does this say 3 hours ago?” confusion.
How the Setting Is Used
- Scheduled jobs: Cron expressions are interpreted in this timezone unless overridden per job.
- Audit timestamps: Internal logs use this timezone when no user is signed in.
- Default user timezone: New users inherit this; they can override in their preferences.
- Date-only fields: Stored without a timezone but interpreted as “midnight in this zone”.
- Reports: Aggregations like “orders today” use this zone to define the day boundary.
Recommended Values
- UK-based platform:
Europe/London. - US East Coast:
America/New_York. - US West Coast:
America/Los_Angeles. - EU multi-country: Often
Europe/BrusselsorUTC. - Global platform:
UTC— neutral, no DST confusion.
UTC vs Local
Many engineers default to UTC for clarity and DST avoidance. Many product teams default to local time so business reports match what stakeholders expect. There's no single right answer — but pick one philosophy and stick to it.
Worked Examples
- UK SaaS: Europe/London. Business reports show the UK day clearly; daylight-savings is handled automatically.
- Global platform: UTC. All scheduled jobs are unambiguous; users see their local time per their preference.
- Multi-region tenant: Each tenant overrides; reports for the German tenant show their local day, US tenant shows theirs.
- Cross-time-zone team: UTC site default; users in different countries see localised times in the UI but APIs return ISO with offsets.
Warning: Don't switch the platform-wide timezone after data exists. Historical timestamps will appear to “shift”. If you must, document and communicate clearly.