This guide explains how MuseRelay handles date and time so the platform stays technically robust while remaining user-friendly for every team member.
1) Technical base: server and database in UTC
MuseRelay uses UTC as the base on server and database. This prevents common distributed-system issues:
- Daylight saving time shifts.
- Cross-country timezone mismatches.
- Inconsistent event comparisons across regions.
Result: data is stored consistently and displayed later in the correct timezone/format.
2) Configuration layers: which setting controls what
Business operations (organization)
Organization settings control operational behavior: calendars, chatbots, bookings, automations, and public-facing flows.
Set this in Organization Settings.
UI display (user profile)
User profile controls visual date/time formatting for each person (day/month order, 12h/24h, etc.).
Set this in Profile. It does not change operational logic.
3) Quick example
- Organization timezone:
America/Mexico_City(operations). - User A: European visual format (24h).
- User B: US visual format (12h).
Both users see the same appointment with their preferred UI format, while core operation follows the organization timezone.
4) Why this design is recommended
- Global scalability: works consistently for teams in China, Japan, USA, or Spain.
- Fewer bugs: UTC backend reduces ambiguity.
- Better UX: each user sees familiar formatting.
- Consistent operations: business logic shares a common organizational time base.
5) Architecture principle
This is not an end-user checklist. It is an architecture decision to keep multi-country operation consistent.
Practical principle: UTC to store, organization to operate, profile to display UI.