Timezones

StatusDashboard stores all event times in UTC and converts them for display based on each user's browser timezone. When you create or edit an event in the admin console, date and time pickers use your local time; visitors to status dashboards see the same moments in their own timezone.

---

How timezones work

StatusDashboard stores all event times in UTC and converts them to local time when displaying them. No timezone configuration is required — everything is derived automatically from each user's browser.

Creating and editing events

When you use a date and time picker in the event form, the times you see and enter are in your browser's local timezone. The picker reflects your computer's current timezone setting.

When you save, those times are converted to UTC before being sent to StatusDashboard. UTC is what gets stored in the database.

Viewing times in the admin

Wherever a timestamp appears — in event lists, on the event detail page, on the timeline — it is displayed in your browser's local timezone, including the abbreviated timezone name (for example, May 8, 2026 at 2:30 PM EDT).

Viewing times on the status dashboard

Visitors to your status dashboard see all times converted to their own browser's local timezone. A visitor in Tokyo and a visitor in Chicago will see the same event with different clock times, both correct for where they are. Timeline entries and event durations are also shown in relative terms ("3 hours ago") for events that occurred recently.

Team members in different timezones

Because the underlying data is always UTC, everyone on your team can work in their own timezone without coordination. If someone in London creates a maintenance window at 9:00 AM GMT and a colleague in New York opens the same event, they will see 4:00 AM EST — the same moment in time, displayed correctly for each person.

If your team uses a shared reference timezone (for example, you always communicate in UTC or in your headquarters timezone), just note that what you see in the form is your local time, not that reference. If you need to set a maintenance window for a specific UTC time, convert it to your local time before entering it.

Daylight saving time

Because times are stored in UTC and converted to local time at display time by the browser, daylight saving transitions are handled automatically. When your clocks change, existing event timestamps will display with the new offset without any changes needed.

There are two edge cases worth knowing about:

Spring forward. In timezones that observe spring-forward transitions, clocks skip one hour (typically from 2:00 AM to 3:00 AM). Any local time that falls in the skipped hour does not exist. If you enter a time in that window, your browser will shift it forward to the next valid time.

Fall back. In timezones that observe fall-back transitions, one hour repeats (clocks go from 2:00 AM back to 1:00 AM). If you enter a time that falls in the repeated hour, your browser will interpret it as the first occurrence — the time before the clocks fell back.

Neither of these situations affects how stored events are displayed — they are only relevant if you are manually entering a start time that happens to land in a transition hour, which is uncommon in practice. For backdating an incident by hours or days, there is no issue.