scheduling agent booked an interview across the daylight-saving chan

Not specified by the original author.

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.

2. 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.

3. 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.

4. 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.

5. 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_ODkJ8Ac6xpOq86NJ8BCwZw

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

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

TL;DR:

Not specified by the original author.

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.

2. 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.

3. 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.

4. 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.

5. 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

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

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

TL;DR:

Not specified by the original author.

TL;DR

Fix this in interview invite scheduling by acting on the exact problem first: compare the interview time held in the ATS with the time on the sent invite for one candidate, find the conversion step that applied the pre change offset, correct the stored interview time in the ATS to the intended local time, reissue invites for every interview falling in the two weeks after the change, and confirm each reissued invite matches its ATS record. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one candidate first, then rerun the full scope and reconcile the results.

how to fix daylight saving interview error candidate invite shifts after DST change fails error

Use this when

• The operation in interview invite scheduling fails with this exact problem: how to fix daylight saving interview error candidate invite shifts after DST change fails error.
• The same failure repeats on retry with unchanged inputs.
• An interview, a panel booking or a candidate confirmation is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor. Resolve that first, then return here if this problem remains.
• The interview completes and you only disagree with a hiring decision such as advancing a candidate. That is a hiring call, not this failure.

Steps

1. Reproduce the failure on one named candidate in interview invite scheduling and record the full problem text plus the candidate, requisition or panel involved. Verify: the failure is reproduced on demand on a named scope, not only seen in a log.
2. Apply the specific fix for this problem: compare the interview time held in the ATS with the time on the sent invite for one candidate, find the conversion step that applied the pre change offset, correct the stored interview time in the ATS to the intended local time, reissue invites for every interview falling in the two weeks after the change, and confirm each reissued invite matches its ATS record. Verify: the single failing candidate now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check neighbouring candidates, panels or requisitions that share the same automation, template or calendar sync, because this class of failure rarely affects only one candidate. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in interview invite scheduling on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result against the source of truth, the ATS candidate record, the interviewer calendars or the booked calendar event, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the candidate record so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

how to fix daylight saving interview error candidate invite shifts after DST change fails error

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single candidate proof, then the full rerun.

How to fix - how to fix daylight saving interview error candidate invite shifts after DST change fails error

The how to phrasing for the same failure in interview invite scheduling. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

interview invite scheduling troubleshooting for this failure

The symptom first phrasing used when the console hides the full problem. Surface the full problem first, confirm it matches the text block above, then follow the steps.

Why it happens

Bulk invite generation converts every interview with the offset in force at generation time, so interviews after the change inherit a stale offset as a batch until the stored times are corrected and the batch is reissued.

Edge cases

• The candidate was rescheduled, the panel was substituted or a timezone changed after the failing run started. Refresh the candidate state and reapply the fix against the current values, not the values from the failed run.
• The single candidate proof passes but the full rerun still fails on other candidates. Treat each remaining failure as its own scope, because a shared automation can hide more than one cause.
• The source systems disagree on the correct value. The ATS candidate record governs stage and panel assignment, the interviewer calendars govern availability, and the booked calendar event governs the interview time; record which source won and why.

Compatibility: interview invite scheduling at current versions, plus the ATS, calendar or video platform the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

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

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

Thread query: how to fix daylight saving interview error candidate invite shifts after DST change fails error

TL;DR: Fix this in interview invite scheduling by acting on the exact problem first: compare the interview time held in the ATS with the time on the sent invite for one candidate, find the conversion step that applied the pre change offset, correct the stored interview time in the ATS to the intended local time, reissue invites for every interview falling in the two weeks after the change, and confirm each reissued invite matches its ATS record. Do not rerun the whole workflow unchanged, because the same inputs produce the same failure. Prove the fix on one candidate first, then rerun the full scope