Timezone-Bewuste Interview Plannen, Correct Gedaan
Het "9:00 AM" Probleem
Beeld dit in: een recruiter in San Francisco plant een 9:00 AM interview met een kandidaat in Berlijn. De recruiter typt "9:00 AM" in een datumkiezer, drukt opslaan, en gaat naar bed voelend produktief. De kandidaat in Berlijn ziet "6:00 PM" — perfect, eind van hun werkdag. Hun aanwervingsmanager, op een stop in Singapore, ziet "12:00 AM" — en gaat ervan uit dat iemand een fout heeft gemaakt.
Drie personen, één interview, drie wandelkloktijden. Als een van hen mentaal wrong vertaalt, zit iemand alleen in een videokamer terwijl de anderen zich afvragen waar ze zijn.
Remote aanwerving loopt op deze breuklijn elke dag. Tot vandaag deed ClarityHire wat de meeste planningstools doen: sla de tijd op en laat elke kijker's browser het om te zetten naar hun lokale zone. Dat werkt — tot het niet meer werkt. Op het moment dat een recruiter "Ik stuur je de 9:00 AM Pacific slot" zegt maar de e-mail "5:00 PM" aan een kandidaat in Londen toont die ook reizen, wint dubbelzinnigheid.
Deze release herstelt dat. Interviews dragen nu een expliciete timezone die de planner koos, gescheiden van elke kijker's lokale zone. We renderen beide, zij aan zij, dus er is precies één wandelklokktijd dat het interview vertegenwoordigt — en een tweede voor "jouw tijd, voor het geval je vergat dat je morgen vliegt."
Wat Onder de Motorkap Veranderd
Drie veranderingen, allemaal klein, allemaal waard om correct te krijgen:
1. We slaan IANA timezones op, niet offsets. "America/Los_Angeles" overleeft een daylight savings transitie. "UTC-8" doet dat niet. Een interview gepland in november voor januari zou stil verschuiven met een uur als we offsets opsloegen. IANA Namen waarborgen dat de wandelklokktijd de planner bedoeld is de wandelklokktijd dat afvuurt, zelfs over DST grenzen.
2. De planner kiest een timezone expliciet. Het schema dialoog heeft nu een timezone selector die de browser zone van de planner uitstelt maar kan worden overschreven. Als je een US recruiter bent die namens een Europese aanwervingsmanager die graag in CET plant meld, kan je dat — en de kandidaat's uitnodiging toont CET als de kanoniekeq zone met hun eigen zone als beleefdheidsvertaling.
3. Wandelklok + zone, niet alleen een instant. De datetime-local input vertegenwoordigt wat een mens typte. We converteren dan die wandelklokktijd naar UTC gebruikende de gekozen timezone — niet de browser's. Dit is de subtiele bug de meeste kalendertools hebben: ze behandelen de input als browser-lokaal zelfs wanneer dropdown "Berlijn" zegt. We gebruiken Intl.DateTimeFormat om de werkelijke offset van de gekozen zone op dat wandelklok instant te berekenen en toe te passen. Geen moment-timezone, geen extra dependency — net een paar goed-geteste coderegels.
Wat Je in de UI Ziet
Het schema dialoog kreeg een Globe-pictogram en een timezone selector met een samengestelde lijst van veel voorkomende zones. Als je browser's timezone niet op de lijst staat (we zien je, Pacific/Pitcairn), het wordt automatisch voorgezet. Zodra je een datum, tijd en zone kiest, een klein voorbee toont hoe de tijd in je lokale zone eruitziet — nuttig als je in een collega's tijd plant en wilt saniteitscontrol je niet een 3 AM-oproep zet.
Op de interview detailpagina renderen geplande tijden nu in de kanoniekeq timezone met een voetnoot "Jouw tijd" wanneer de kijker's zone verschilt. Kandidaat tijdlijnen doen hetzelfde. De datum filters en analytics queries blijven onder de motorkap in UTC werken, dus rapportering blijft correct ongeacht waar de rijen werden ingevoerd.
Wat E-mail Ontvangers Zien
Interview uitnodigingen — een van de hoogste inzet e-mails we sturen — tonen nu de interview tijd in de timezone de planner koos, met de timezone afkorting ernaast ("9:00 AM PDT"). Geen meer hand-typend "(Pacific)" in de kalender event beschrijving en hopen dat de kandidaat's e-mailcliënt de timezone hint in het .ics bestand respecteert. De wandelklok string in de e-mail is de wandelklok string dat's autoritair.
Een Noot op Kalender Uitnodigingen
Voor .ics kalender bijlagen, IANA timezone Namen zijn het juiste ding om in te bedden. We doen dat. Outlook, Google Calendar, en Apple Calendar interpreteren allemaal IANA zones correct. Als een kandidaat's kalenderapp iets exotisch doet, de e-mail body draagt nog steeds de kanoniekeq "9:00 AM PDT" string als backup — omdat riem en bretels de passende houding is als interview slot op de lijn staat.
Migratie
Bestaande interviews hebben een null timezone. Ze renderen hetzelfde als voorheen — kijker-lokale tijd, geen zone label — dus niets breekt. Ieder interview gepland of opnieuw gepland voortaan pikt een expliciete timezone. Over tijd, de historische gat sluit natuurlijk; we deden niet bulk-backfill, omdat gissen de originele planner bedoelde zone na het feit is precies het soort zelfverzekerde-maar-verkeerde zet deze hele feature bedoeld te voorkomen.
Waarom Dit Voorbij Interviews Belangrijk
Dezelfde probleem toont zich in deadline herinneringen ("voltooid door 11:59 PM" — van wie 11:59?), test vensters, en SLA timers. We beginnen met interviews omdat dat's waar dubbelzinnigheid het meest kost: een gemiste test deadline kan opnieuw worden uitgebreid; een gemist interview betekent de kandidaat vraagt zich af of je je zaak op orde hebt. Vertrouwen is moeilijk opnieuw op te bouwen en makkelijk door te brengen. Dus we brachten de engineering uren waar de trust budget dunst is.
Als je ooit "Sorry, ik denk dat ik de verkeerde timezone had" Slack bericht op 9:01 AM moest sturen, deze is voor je.