Pianificazione di Colloqui Consapevole dei Timezone, Fatto Bene

Il Problema "9:00 AM"

Immaginate questo: un recruiter a San Francisco pianifica un colloquio delle 9:00 AM con un candidato a Berlino. Il recruiter digita "9:00 AM" in un date picker, fa clic su salva, e va a letto sentendosi produttivo. Il candidato a Berlino vede "6:00 PM" — perfetto, fine della loro giornata lavorativa. Il loro hiring manager, in uno scalo a Singapore, vede "12:00 AM" — e assume che qualcuno abbia commesso un errore.

Tre persone, un colloquio, tre wall-clock time. Se uno di loro traduce mentalmente in modo scorretto, qualcuno è seduto da solo in una video room mentre gli altri si chiedono dove sono andati.

L'assunzione remota gira su questa linea di faglia ogni giorno. Fino ad oggi, ClarityHire ha fatto quello che la maggior parte dei strumenti di pianificazione fa: memorizza il tempo e lascia che il browser di ogni viewer lo converta nella loro zona locale. Funziona — fino a quando non lo fa. Nel momento in cui un recruiter dice "Ti manderò lo slot di 9:00 AM Pacific" ma l'email mostra "5:00 PM" a un candidato a Londra che è anche in viaggio, l'ambiguità vince.

Questo release lo risolve. I colloqui ora portano un timezone esplicito che lo scheduler ha scelto, separato dalla zona locale di ogni viewer. Renderizziamo entrambi, uno accanto all'altro, così c'è esattamente un wall-clock time che rappresenta "il colloquio" — e un secondo per "il vostro tempo, nel caso abbiate dimenticato che state volando domani."

Cosa è Cambiato Sotto il Cofano

Tre cambiamenti, tutti piccoli, tutti degni di ottenere bene:

1. Memorizziamo timezone IANA, non offset. "America/Los_Angeles" sopravvive a una transizione di daylight saving. "UTC-8" non lo fa. Un colloquio pianificato a novembre per gennaio cambierebbe silenziosamente un'ora se memorizzassimo offset. I nomi IANA assicurano che il wall-clock time che lo scheduler intendeva sia il wall-clock time che si attiva, anche attraverso i confini del DST.

2. Lo scheduler sceglie un timezone esplicitamente. Il dialogo di pianificazione ora ha un selettore di timezone che predefinisce la zona del browser dello scheduler ma può essere override. Se siete un recruiter di US che pianifica per conto di un hiring manager europeo che ama pianificare in CET, potete — e l'invito del candidato mostrerà CET come la zona canonica con la loro zona come traduzione di cortesia.

3. Wall-clock + zone, non solo un instant. L'input datetime-local rappresenta quello che un umano ha digitato. Convertiamo poi quel wall-clock time a UTC usando il timezone scelto — non il browser. Questo è il bug sottile che la maggior parte degli strumenti di calendaring ha: trattano l'input come browser-local anche quando il dropdown dice "Berlin." Usiamo Intl.DateTimeFormat per computare l'offset effettivo del timezone scelto a quel wall-clock instant e lo applichiamo. No moment-timezone, nessuna dipendenza aggiuntiva — giusto poche righe di codice carefully-tested.

Cosa Vedete nell'UI

Il dialogo di pianificazione ha guadagnato un'icona Globe e un selettore di timezone con una lista curata di zone comuni. Se il vostro timezone del browser non è nella lista (vi vediamo, Pacific/Pitcairn), viene anteposto automaticamente. Non appena scegliete una data, ora, e zona, un piccolo preview mostra che aspetto ha il tempo nella vostra zona locale — utile quando state pianificando nel tempo di un collega e volete sanity-check che non state mettendoli in una chiamata di 3 AM.

Sulla pagina di dettaglio del colloquio, i tempi pianificati ora si renderizzano nel timezone canonico con una nota a pie di pagina "Il vostro tempo" ogni volta che la zona del viewer differisce. Le timeline del candidato fanno lo stesso. I filtri di data e le query di analitiche continuano a lavorare in UTC sotto il cofano, così il reporting rimane corretto indipendentemente da dove le righe sono state inserite.

Cosa Ricevono i Destinatari di Email

Gli inviti di colloquio — una delle email ad altissimo rischio che inviamo — ora visualizzano il tempo del colloquio nel timezone che lo scheduler ha scelto, con l'abbreviazione di timezone proprio accanto ("9:00 AM PDT"). Niente più digitazione manuale "(Pacific)" nella descrizione dell'evento di calendario e preghiera che il client email del candidato rispetti il suggerimento di timezone nel file .ics. Il wall-clock string nell'email è il wall-clock string che è autoritario.

Una Nota sugli Inviti di Calendario

Per gli allegati del calendario .ics, i nomi di timezone IANA sono la cosa giusta da incorporare. Lo facciamo. Outlook, Google Calendar, e Apple Calendar tutti interpretano i timezone IANA correttamente. Se il client di calendario di un candidato fa qualcosa di esotico, il corpo dell'email porta ancora il wall-clock string canonico "9:00 AM PDT" come backup — perché cintura e bretelle è il posizionamento appropriato quando uno slot di colloquio è in gioco.

Migrazione

I colloqui esistenti hanno un timezone null. Si renderizzano come prima — wall-clock time locale al viewer, nessuna label di zone — così niente si rompe. Qualsiasi colloquio pianificato o ripianificato da ora in poi raccoglie un timezone esplicito. Nel tempo, il gap storico si chiude naturalmente; non abbiamo bulk-backfilled, perché indovinare il timezone inteso originale dello scheduler dopo il fatto è esattamente il tipo di mossa confident-but-wrong che questa intera feature è intesa per prevenire.

Perché Questo Importa Al di Là dei Colloqui

Lo stesso problema appare nei promemoria ("completa entro 11:59 PM" — di chi?), finestre di test, e timer di SLA. Stiamo iniziando con i colloqui perché è dove l'ambiguità costa di più: un deadline di test mancato può essere re-extended; un colloquio mancato significa che il candidato si chiede se avete il vostro atto insieme. La fiducia è difficile da ricostruire e facile da spendere. Così abbiamo speso le ore di engineering dove il budget di fiducia è il più sottile.

Se avete mai avuto bisogno di mandare un messaggio di Slack "mi scusi, penso di avere il timezone sbagliato" alle 9:01 AM, questo è per voi.