タイムゾーン対応の面接スケジューリング、正しい方法で

「午前9時」の問題

想像してください：サンフランシスコの採用担当者がベルリンの候補者と午前9時の面接をスケジュールしています。採用担当者は日付ピッカーに「午前9時」と入力し、保存してから生産性を感じて寝ます。ベルリンの候補者は「午後6時」を見ています—完璧で、彼らの労働日の終わり。シンガポールの乗り継ぎにいるマネージャーは「午前12時」を見ています—そして誰かが間違いを犯したと仮定しています。

3人、1つの面接、3つの壁時計。彼らのいずれかが精神的に間違って翻訳した場合、誰かはビデオルームで一人で座っています。

リモート採用はこの障害線で毎日実行されます。今日まで、ClarityHireはほとんどのスケジューリングツールがするように何をしていました：時間を保存し、各ビューアのブラウザがそれをローカルゾーンに変換するようにしてください。 それは機能します—それは機能しないまで。採用担当者が「午前9時太平洋スロット」を送信するという瞬間ですが、電子メールは「午後5時」をロンドンの候補者に表示します。また旅行しています。曖昧さが勝ちます。

このリリースはそれを修正します。インタビューは現在、スケジューラーが選んだ明示的なタイムゾーンを運ぶ。各ビューアのローカルゾーンと分離。私たちは両方をレンダリングします。そのため、「インタビュー」を表す正確に1つの壁時計—「あなたの時間」の2番目のもの、あなたが明日飛んでいることを忘れていた場合。

フードの下で何が変わったのか

3つの変更、すべて小さく、すべて正しく取得する価値があります：

1. IANAタイムゾーンを保存しています。 「America/Los_Angeles」は夏時間遷移を生き残ります。「UTC-8」はそうではありません。11月にスケジュールされた面接は1月でしたが、オフセットを保存した場合、サイレントシフトが1時間。IANA名は、スケジューラーが意図した壁時計時間がDST境界を越えた壁時計時間であることを保証します。

2. スケジューラーは明示的にタイムゾーンを選択します。 スケジュールダイアログはタイムゾーンセレクターを取得し、スケジューラーのブラウザゾーンにデフォルトしますが、オーバーライドできます。あなたが米国の採用担当者で、CETで計画するのが好きなヨーロッパの採用マネージャーの代わりにスケジュール設定している場合、あなたは可能です—候補者の招待はCETを正規のゾーンとして独自のゾーンを礼儀翻訳として表示します。

3. 壁時計+ゾーン、直ぐに。 datetime-local入力は、人間が入力したものを表します。その後、その壁時計時間をUTCに変換します。選択されたタイムゾーンを使用—ブラウザの。これは、ほとんどのカレンダリングツールが持っている微妙なバグです：ドロップダウンが「ベルリン」と言っても、入力をブラウザローカルとして扱います。 私たちはIntl.DateTimeFormatを使用して、その壁時計の瞬間に選択されたゾーンの実際のオフセットを計算し、それを適用します。 moment-timezoneなし、余分な依存関係なし—数行の慎重にテストされたコードだけ。

UIで何を見ますか

スケジュールダイアログはグローブアイコンと、一般的なゾーンの厳選されたリストを持つタイムゾーンセレクターを獲得しました。ブラウザのタイムゾーンがリストに含まれていない場合（私たちはあなたを見ます。Pacific/Pitcairn）。日付を選択するとすぐに、小さなプレビューが表示されます。あなたのローカルゾーン—同僚の時間にスケジュール設定していて、彼らを午前3時に呼ぶようにしていないことを確認したい場合に便利です。

インタビューの詳細ページでは、スケジュールされた時間が正規のタイムゾーンで現在レンダリングされます。「あなたの時間」という注釈は、ビューアのゾーンが異なる場合。候補者タイムラインも同様です。日付フィルターと分析クエリは、UIの下でUTC内で動作し続けるため、行がどこで入力されたかに関係なくレポートが正しいままです。

メール受信者が何を見ますか

面接招待—最も高いステークスの電子メールの1つ—現在、スケジューラーが選んだタイムゾーンに表示される面接時間が含まれます。タイムゾーン略語がすぐそばにあります（「午前9時PDT」）。 これ以上、手入力「（太平洋）」をカレンダーイベントの説明に入力することはなく、候補者の電子メールクライアントが.icsファイルのタイムゾーンヒントを尊重することを祈りません。 電子メール本文の壁時計文字列は、権威的な壁時計文字列です。

カレンダー招待状に関する注意

.icsカレンダーの添付ファイルの場合、IANAタイムゾーン名は、埋め込む正しいことです。 私たちはそうします。 Outlook、Google Calendar、およびApple Calendarはすべてが正しくIANAゾーンを解釈します。 候補者のカレンダーアプリが何か異国情緒をする場合、電子メール本文は依然として正規の「午前9時PDT」文字列をバックアップとして表示します—ベルトとサスペンダーは、面接スロットが線上にあるときの適切な姿勢です。

移行

既存のインタビューには、nullタイムゾーンがあります。 彼らは以前と同じようにレンダリングしています—ビューアローカル時間、ゾーンラベルなし—だから何も壊れません。 スケジュールまたは前後にスケジュール設定されたインタビューは、明示的なタイムゾーンを選択します。 時間が経つにつれて、歴史的なギャップは自然に閉じます。 当初のスケジューラーの意図されたゾーンを事実の後に推測するため、一括バックフィルしませんでした。それはこの機能全体が防ぐことを意図した、自信を持っていますが間違ったすべての動きです。

面接を超えた理由

同じ問題は、期限リマインダー（「午後11時59分まで完了」—誰の11:59？）、テストウィンドウ、およびSLAタイマーに表示されます。 インタビューから始まりました。何故なら、曖昧性は最も費用がかかる場所だからです：試験期限の逃した再延長をすることができます。 逃されたインタビューは、候補者があなたが行為をまとめているかどうかを疑問に思います。 信頼は再構築するのは難しく、費やすのは簡単です。 だから私たちは信頼予算が最も薄い場所で技術時間を費やしました。

あなたが午前9時01分に「申し訳ありませんが、私は間違ったタイムゾーンを持っていたと思います」Slackメッセージを送信する必要があった場合、これは1つです。