interview agent booked the candidate in UTC - the invite said 2pm PT in the body but the event was 2pm UTC and the...

TL;DR: Generate the invite body text from the stored calendar event, never from a separate string the scheduler composed. Create the event with the named timezone attached (America/Los_Angeles), then render the body from that event. The candidate showed up 8 hours late because the body said PT while the event was UTC, and the calendar won.

interview agent booked the candidate in UTC  -  the invite said 2pm PT in the body but the event was 2pm UTC and the candidate showed up 8 hours late

1. Read the created event's start time and timezone fields.

Expected: the event stores 14:00 with a UTC marker or no zone, while the body text says 2pm PT.

1. Change the event creation to pass the candidate's named timezone explicitly.

Expected: the event now stores 14:00 with America/Los_Angeles attached.

1. Rewrite the body generator to render the time from the stored event object after creation.

Expected: the body text matches the event's local rendering exactly, because it is derived from it.

1. Re-issue the invite and ask the candidate to confirm the local time shown.

Expected: candidate confirms 2:00 PM Pacific and their calendar shows the same.

1. Add a validation before sending: extract the time from the body text and compare it to the event rendered in the candidate's zone.

Expected: any future mismatch blocks the send instead of reaching the candidate.

Use this when

• The email body and the calendar event show different times for the same interview.
• Candidates arrive hours early or late while the organizer's calendar looked right.
• The scheduler builds invite text separately from the calendar API call.

Not for this skill when

• Both the body and the event are wrong by the same amount (that is a conversion bug, not a disagreement).
• The candidate's own calendar renders the event in the wrong zone (client-side display issue).
• The offset is off by one hour around a DST change (see the daylight-saving skill).

Variant phrasings

• invite body said PT but the event was created in UTC
• candidate showed up 8 hours late for the interview
• email and calendar disagreed on interview time
• scheduler wrote local time in the email but UTC in the event

Why it happens

The interview time existed in two representations: a structured event owned by the calendar API (which defaulted to UTC) and a free-text body owned by the scheduler (which wrote PT). Nothing forced them to agree. The candidate trusted the human-readable body; the reminder and the calendar entry trusted the structured event. Single-source the text from the event and the disagreement becomes impossible.

Edge cases

• A DST transition between booking and interview changes the UTC offset: rendering from the event at send time stays correct only if the zone is attached, not a baked-in offset.
• Candidates reading the body on a phone set to a different zone: the body should name the zone explicitly ("2:00 PM Pacific") so it is unambiguous.
• Recurring interviews: render each occurrence from its own event data.
• The organizer forwarding the invite: forward the calendar event, not the email, so the structured time travels with it.

Provenance

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