Time Shown in Wrong Timezone
An event's start time is stored correctly in UTC but displayed to the user without timezone conversion. The frontend renders the raw UTC hour directly, so a user in America/New_York (UTC−5) who expects to see 3:00 PM EST instead sees 8:00 PM — the unmodified UTC value. This is a UTC↔local conversion error: the stored timestamp is correct, but the display layer never applies the user's timezone offset.
MediumBeginnerManual testingExploratory testingLocalization testing
// UNDERSTAND
// Symptoms
- Event 101 is stored as 2024-11-15T20:00:00Z (8:00 PM UTC) but displays as '8:00 PM' to a user in America/New_York (UTC−5), who expects '3:00 PM'
- All times shown in the UI are correct for users in the UTC+0 timezone but wrong for anyone else
- Events appear to start several hours later or earlier than the real local time
- The same event shows a different time depending on which device or browser the user is on, if each applies a different default timezone
- The timezone label is absent from the displayed time, so users in different timezones assume the shown hour is their local time
// Root Cause
- The display component extracts the hour from the ISO timestamp using new Date('2024-11-15T20:00:00Z').getHours(), which returns the local machine hour only if the client's locale is used — in UTC-0 environments (e.g. server-side rendering or CI) it returns 20, the UTC hour, which is then persisted or cached and served to all users regardless of their timezone
- The time is formatted using a date library call that does not receive an explicit timezone option, so it defaults to the runtime environment's system timezone instead of the user's configured or browser-reported timezone
- The backend returns the ISO UTC timestamp in the API response but also returns a pre-formatted time string (e.g. displayTime: '8:00 PM') computed at the server in UTC — the frontend uses the pre-formatted string instead of converting the raw timestamp
// Where It Appears
- Event booking and scheduling applications where attendees are in different timezones
- Live-stream and webinar platforms that display start times to a global audience
- Notification emails that include an event time formatted on the server in UTC
- Calendar and appointment systems where the stored timezone is UTC but display is local
- Meeting scheduling tools that show invitee-local times
// REPRODUCE & TEST
// How to Reproduce
- 01Create or identify event 101 with a stored UTC start time of 2024-11-15T20:00:00Z
- 02In browser DevTools > Application tab > Sensors (or via OS settings), set the timezone to America/New_York (UTC−5 in November, standard time)
- 03Navigate to the event detail page at /events/101
- 04Observe the displayed start time
- 05The expected display is 3:00 PM EST; the displayed value to confirm the bug is '8:00 PM'
// Test Data Needed
- Event record 101 with starts_at = '2024-11-15T20:00:00Z' in the database
- Browser DevTools with timezone override capability (Chrome Sensors panel) or a VPN/OS set to America/New_York
- A second browser or OS set to a different timezone (e.g. UTC+0) to confirm the disparity
// Manual Testing Ideas
- Set the browser timezone to America/New_York (UTC−5) and verify event 101 shows 3:00 PM; then switch to UTC+0 and verify it shows 8:00 PM — both should be correct local times for the same event
- Test with timezones on either side of the UTC line: UTC+5:30 (India) and UTC−8 (US Pacific) to check positive and negative offsets
- Test at a DST boundary: use a timezone that observes DST (e.g. America/New_York) and check an event time on the DST changeover date (e.g. 2024-03-10 for US spring forward)
- Compare the time shown in the UI against the raw starts_at value from GET /api/events/101 to confirm the stored UTC value is correct
- Check whether the timezone abbreviation (EST, PST, etc.) is shown next to the time — absence of a label is a strong indicator that conversion is not applied
// API Testing Ideas
- Send GET /api/events/101 and confirm the starts_at field is '2024-11-15T20:00:00Z' — this verifies the stored value is correct UTC
- Confirm the API response does not include a pre-formatted displayTime field; if it does, verify that field is correct for the America/New_York timezone (expected: '3:00 PM EST')
- If a user preferences endpoint exists, set the user's timezone to 'America/New_York' and call GET /api/events/101 again to see whether the response changes
// Automation Idea
Write a Playwright test that overrides the browser timezone to 'America/New_York' using the browser context's timezoneId option. Navigate to /events/101 and assert the displayed time text is '3:00 PM' or '3:00 PM EST'. Repeat the test with timezoneId set to 'UTC' and assert the displayed time is '8:00 PM'. A discrepancy between the two (e.g. both show '8:00 PM') confirms the timezone conversion is not applied in the display layer.
// Expected Result
Event 101 (stored as 2024-11-15T20:00:00Z) displays as 3:00 PM EST for a user in America/New_York (UTC−5) and as 8:00 PM UTC for a user in the UTC+0 timezone.
// Actual Result (Example)
Event 101 displays as '8:00 PM' for a user in America/New_York (UTC−5). The expected display is 3:00 PM EST. GET /api/events/101 confirms starts_at is '2024-11-15T20:00:00Z' — the stored UTC value is correct, but the frontend renders the raw UTC hour without applying the −5 offset.
// REPORT IT
Example Bug Report
- Title
- Event 101 shows '8:00 PM' in America/New_York (UTC−5) instead of expected '3:00 PM EST'
- Severity
- Medium
- Environment
- Staging environment Chrome 124 with timezone override: America/New_York (UTC−5) Event 101 — starts_at: 2024-11-15T20:00:00Z
- Steps to Reproduce
- 01Open Chrome DevTools > More Tools > Sensors
- 02Set the Location timezone override to 'America/New_York'
- 03Navigate to /events/101
- 04Read the displayed start time on the event detail page
- 05Compare against the stored UTC value from GET /api/events/101: starts_at = '2024-11-15T20:00:00Z'
- Expected Result
- The event shows '3:00 PM EST' — the correct America/New_York (UTC−5) conversion of 2024-11-15T20:00:00Z.
- Actual Result
- The event shows '8:00 PM' — the raw UTC hour — without a timezone label or offset applied. Users in America/New_York (UTC−5) see an incorrect local time.
- Impact
- Users attend or miss events at the wrong time. For a global audience, the error is as large as the user's UTC offset — up to 12+ hours in extreme cases — making the feature unusable outside the UTC+0 timezone.