## TL;DR
Meeting times are stored as a single instant and displayed in each viewer's timezone, so a wrong device setting or a daylight saving change makes the same event show different times to different people. Tell the user: the event is fine, the display is translating it. Then check the three usual suspects in order: the device timezone setting, the timezone the event was created in, and whether a daylight saving transition sits between creation and the event.

## The query

```text
timezone bugs in scheduling apps: support explanation
```

## Use this when

- A user says a meeting shows at the wrong time
- Event times shifted after travel or a daylight saving change
- Two people see different times for the same event
- You are writing a help article on timezone behavior

## Not for

- Building timezone handling in code
- Calendar sync engineering (CalDAV, Exchange)
- Recurring-event logic design
- Timezone database updates

## Steps

### 1. Get both sides of the story

Ask what time the user expected, what time they see, and their current timezone. A screenshot showing the event with the timezone label visible is worth three messages of description. You need expected versus actual before anything else.

Expected output: the expected time, the displayed time, and the user's timezone.

### 2. Check the device and OS timezone setting

The most common cause: the laptop or phone is set to the wrong zone, often left over from travel. The app renders correctly for the zone it is told, which isnt the zone the user is in. Have them verify the OS setting, not just the app setting.

Expected output: the OS timezone matches where the user actually is, or the mismatch is found.

### 3. Check the timezone the event was created in

An event created as 3pm Pacific while traveling shows as 6pm Eastern back home, and users read that as a bug. Check the event's original timezone (usually in event details) and confirm it matches what the organizer intended.

Expected output: the creation timezone is confirmed correct or identified as the surprise.

### 4. Check for a daylight saving transition in between

Events scheduled across a spring-forward or fall-back change shift by an hour for some attendees and not others, depending on each zone's transition date. If the complaint is exactly one hour and the date is near a transition, this is almost certainly it.

Expected output: a confirmed or ruled-out DST transition explaining the one-hour shift.

### 5. Give the user the mental model and a workaround

Explain it once in plain words: the meeting is pinned to a moment, and each device translates it to local time. For critical meetings, put the timezone in the invite title or description ("3pm PT / 6pm ET") so nobody has to trust the translation.

Expected output: the user understands the behavior and has a practical workaround.

## Ready-to-use reply

```text
The meeting itself is fine, what you are seeing is a timezone
translation. The event is pinned to one moment in time, and your
device converts it to your local timezone. Can you check your phone
or laptop timezone setting matches where you are right now? That is
the cause in most cases. For important meetings I also recommend
putting the timezone in the invite itself, like "3pm PT", so there is
no guessing.
```

## Variant phrasings

### meeting time wrong after traveling

Steps 2 and 3. Travel leaves the OS setting behind and changes which translation the user sees.

### calendar event shifted by one hour

Step 4 first. Exactly one hour near a transition date is daylight saving.

### why do invitees see a different time than me

Step 5. This is the expected behavior to explain, not a bug to fix.

## Why it happens

Computers store event times as timezone-free instants (UTC) and convert to local time on display. That design is correct, it is what lets a global team share one calendar, but it means every link in the chain (creation zone, device zone, DST rules) can shift what the user sees. Users experience the translation as the event moving, when really their viewing lens moved.

## Edge cases

- All-day events shifting a day: all-day blocks are often stored as midnight in some zone, and a far-away viewer sees them start the previous evening. Known quirk, explain and move on.
- Recurring events across DST: the series keeps the local wall-clock time but individual instances may show oddly around transitions. Check one instance, not the series.
- Imported events with no zone info: CSV and API imports sometimes arrive zone-less and get stamped with the importer's zone. Ask how the event got in.
- The user is right and it is a real bug: if all settings check out and times still disagree between two viewers in the same zone, escalate with both screenshots.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tmcFT89Y6bYgZOACGJbDvA