Timezone-Aware Interview Scheduling, Done Right
The "9:00 AM" Problem
Picture this: a recruiter in San Francisco schedules a 9:00 AM interview with a candidate in Berlin. The recruiter types "9:00 AM" into a date picker, hits save, and goes to bed feeling productive. The candidate in Berlin sees "6:00 PM" — perfect, end of their workday. Their hiring manager, on a layover in Singapore, sees "12:00 AM" — and assumes someone made a mistake.
Three people, one interview, three wall-clock times. If any of them mentally translates wrong, somebody is sitting alone in a video room while the others wonder where they went.
Remote hiring runs on this fault line every day. Until today, ClarityHire did what most scheduling tools do: store the time and let each viewer's browser convert it to their local zone. That works — until it doesn't. The moment a recruiter says "I'll send you the 9:00 AM Pacific slot" but the email shows "5:00 PM" to a candidate in London who is also travelling, ambiguity wins.
This release fixes that. Interviews now carry an explicit timezone the scheduler chose, separate from each viewer's local zone. We render both, side by side, so there is exactly one wall-clock time that represents "the interview" — and a second one for "your time, in case you forgot you're flying tomorrow."
What Changed Under the Hood
Three changes, all small, all worth getting right:
1. We store IANA timezones, not offsets. "America/Los_Angeles" survives a daylight savings transition. "UTC-8" does not. An interview scheduled in November for January would silently shift by an hour if we stored offsets. IANA names ensure the wall-clock time the scheduler intended is the wall-clock time that fires, even across DST boundaries.
2. The scheduler picks a timezone explicitly. The schedule dialog now has a timezone selector that defaults to the scheduler's browser zone but can be overridden. If you are a US recruiter scheduling on behalf of a European hiring manager who likes to plan in CET, you can — and the candidate's invite will show CET as the canonical zone with their own zone as a courtesy translation.
3. Wall-clock + zone, not just an instant. The datetime-local input represents what a human typed. We then convert that wall-clock time to UTC using the chosen timezone — not the browser's. This is the subtle bug most calendaring tools have: they treat the input as browser-local even when the dropdown says "Berlin." We use Intl.DateTimeFormat to compute the actual offset of the chosen zone at that wall-clock instant and apply it. No moment-timezone, no extra dependency — just a few lines of carefully-tested code.
What You See in the UI
The schedule dialog gained a Globe icon and a timezone selector with a curated list of common zones. If your browser's timezone isn't on the list (we see you, Pacific/Pitcairn), it's prepended automatically. As soon as you pick a date, time, and zone, a small preview shows what the time looks like in your local zone — useful when you're scheduling in a colleague's time and want to sanity-check you're not putting them in a 3 AM call.
On the interview detail page, scheduled times now render in the canonical timezone with a "Your time" footnote whenever the viewer's zone differs. Candidate timelines do the same. The date filters and analytics queries continue to work in UTC under the hood, so reporting stays correct regardless of where the rows were entered.
What Email Recipients See
Interview invites — one of the highest-stakes emails we send — now display the interview time in the timezone the scheduler chose, with the timezone abbreviation right next to it ("9:00 AM PDT"). No more hand-typing "(Pacific)" into the calendar event description and praying the candidate's email client respects the timezone hint in the .ics file. The wall-clock string in the email is the wall-clock string that's authoritative.
A Note on Calendar Invites
For .ics calendar attachments, IANA timezone names are the right thing to embed. We do that. Outlook, Google Calendar, and Apple Calendar all interpret IANA zones correctly. If a candidate's calendar app does something exotic, the email body still carries the canonical "9:00 AM PDT" string as a backup — because belt and suspenders is the appropriate posture when an interview slot is on the line.
Migration
Existing interviews have a null timezone. They render the same as before — viewer-local time, no zone label — so nothing breaks. Any interview scheduled or rescheduled going forward picks up an explicit timezone. Over time, the historical gap closes naturally; we did not bulk-backfill, because guessing the original scheduler's intended zone after the fact is exactly the kind of confident-but-wrong move this whole feature is meant to prevent.
Why This Matters Beyond Interviews
The same problem shows up in deadline reminders ("complete by 11:59 PM" — whose 11:59?), test windows, and SLA timers. We are starting with interviews because that's where ambiguity costs the most: a missed test deadline can be re-extended; a missed interview means the candidate questions whether you have your act together. Trust is hard to rebuild and easy to spend. So we spent the engineering hours where the trust budget is thinnest.
If you've ever had to send a "so sorry, I think I had the wrong timezone" Slack message at 9:01 AM, this one's for you.