scheduling agent booked an interview across the daylight-saving change - the 9am PT slot shifted an hour for the...

TL;DR: Store every interview in UTC with the IANA timezone attached (America/Los_Angeles, not a fixed -08:00) and let the zone database compute the offset for the actual date. The 9am PT slot never moved - the agent's conversion did, because Pacific shifts between -08:00 and -07:00. Regenerate any invite text from the stored event so the body and the calendar agree.

scheduling agent booked an interview across the daylight-saving change  -  the 9am PT slot shifted an hour for the candidate after the switch

1. Read the event's stored start time and timezone field.

Expected: it shows a bare offset like -08:00 or a UTC time computed from one, with no named zone attached.

1. Find where the scheduler converts local time to UTC and check whether it hardcodes the offset.

Expected: the code subtracts a constant (e.g. 8 hours) instead of looking up the offset for the event date.

1. Change the conversion to use the IANA zone for the event's date, and store both the UTC time and the zone name.

Expected: a test booking for a date after the switch stores the correct UTC instant for 9:00 AM Pacific.

1. Re-issue the affected invites and confirm with the candidate that the invite reads 9:00 AM Pacific.

Expected: the candidate's calendar and the body text both show 9:00 AM local.

1. Add a pre-send check: convert the stored UTC instant back into each participant's zone and compare against the intended local time.

Expected: the check fails loudly if the rendered time ever drifts from 9:00 AM.

Use this when

• Interview times shift by exactly one hour around the spring or fall DST transition.
• The scheduler converts times with a hardcoded offset instead of a timezone name.
• Candidates in zones that observe DST report wrong times while others are fine.

Not for this skill when

• The time is wrong by a non-hour amount (that is a different bug, likely a zone mixup).
• The calendar provider renders the event correctly but the agent's email body text is wrong (fix the body generation instead).
• The interview was booked in a zone that does not observe DST at all.

Variant phrasings

• interview time moved an hour after the clocks changed
• scheduler used the wrong UTC offset after daylight saving
• 9am PT interview showed as 8am for the candidate in spring
• hardcoded -08:00 broke interview scheduling in summer

Why it happens

Pacific time is UTC-08:00 in winter and UTC-07:00 in summer. Any code that bakes in one offset produces the right answer only half the year, and the bug surfaces exactly twice a year on transition weekends. The fix is to never do arithmetic with offsets yourself: attach the zone name to the event and let the tz database resolve the offset for that date.

Edge cases

• Interviews booked inside the missing hour on spring-forward day (2:00-3:00 AM does not exist): the zone lookup must reject or shift these explicitly.
• The duplicated hour on fall-back day: an event at 1:30 AM is ambiguous. Record which occurrence was intended.
• Recurring interviews crossing a transition: each occurrence needs its own offset lookup, not one computed at series creation.
• Candidates who moved zones between booking and interview: re-render in their current zone and confirm.

Provenance

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