चेकआउट से पहले जाँचना कि पता अपने बताए गए पिन कोड से मेल खाता है
ऑर्डर फ़ॉर्म पर पिन कोड और शहर का मेल न खाना एक छोटी सी टाइपिंग गलती लगती है, जब तक कि वह देश के बिल्कुल गलत हिस्से में भेजी गई डिलीवरी में न बदल जाए।
अलग-अलग समय क्षेत्रों में रिमोट टीम का समन्वय
"UTC माइनस पाँच" कोई समय क्षेत्र नहीं है, यह एक ऑफ़सेट है, और डेलाइट सेविंग मानने वाले ज़्यादातर देशों में ऑफ़सेट साल में दो बार बदलते हैं, और ठीक इसीलिए बारह लोगों की एक रिमोट टीम ऐसी मीटिंग शेड्यूल करती रही जो महीनों तक सही समय पर पड़ीं और फिर अचानक नहीं पड़ीं, ठीक किसी ऐसे घड़ी बदलाव के आसपास जिसे शेड्यूल करने वालों में से किसी ने जाँचने के बारे में सोचा ही नहीं था।
टीम एक सरल स्प्रेडशीट रखती थी जिसमें हर साथी का शहर कंपनी मुख्यालय से एक तय ऑफ़सेट से जुड़ा था, और जब भी किसी को याद आता कि डेलाइट सेविंग आने वाली है, इसे हाथ से अपडेट किया जाता था। यह स्प्रेडशीट साल के लगभग छह महीने, बारी-बारी से, गलत रहती थी, इस पर निर्भर करते हुए कि किन देशों ने अपनी घड़ियाँ बदली थीं और किन्होंने नहीं, क्योंकि हर देश एक ही कार्यक्रम पर डेलाइट सेविंग नहीं मानता, और कुछ इसे बिल्कुल नहीं मानते।
समाधान था स्प्रेडशीट की जगह ऐसा लुकअप लगाना जो किसी के एक बार टाइप किए गए स्नैपशॉट के बजाय समय क्षेत्र के असली नियमों को दर्शाए। हर साथी के शहर के लिए टीम ने एक निर्देशांक निकाला और उसे /v1/timezone पर भेजा, जो उस बिंदु के लिए IANA समय क्षेत्र का नाम लौटाता है, यानी सिर्फ़ ऑफ़सेट के बजाय "America/Sao_Paulo" या "Asia/Kolkata" जैसा नाम। यह नाम उस खास क्षेत्र के असली डेलाइट सेविंग नियम अपने साथ रखता है, इसलिए जो शेड्यूलिंग टूल ऑफ़सेट को सीधे स्टोर करने के बजाय IANA नाम स्टोर करता है और उससे मौजूदा ऑफ़सेट की गणना करता है, वह घड़ियाँ बदलने पर अपने आप सही बना रहता है, क्योंकि नियम समय क्षेत्र डेटाबेस में रहते हैं, न कि किसी ऐसे मान में जिसे अपडेट करना किसी को याद रखना पड़े।
टीम ने इसे सीधे अपने मीटिंग शेड्यूलिंग टूल में जोड़ दिया, ताकि मीटिंग का समय प्रस्तावित करते ही हर प्रतिभागी का स्थानीय समय सही दिखे, जिसकी गणना किसी स्थिर तालिका से लेने के बजाय मीटिंग शेड्यूल करने के पल ही नए सिरे से होती थी। हफ़्तों पहले प्रस्तावित मीटिंग के लिए, एंडपॉइंट की किसी खास भविष्य के पल के लिए ऑफ़सेट निकालने की क्षमता भी मायने रखती थी, क्योंकि किसी क्षेत्र की घड़ी बदलने से पहले शेड्यूल और उसके बाद होने वाली मीटिंग को बदलाव के बाद वाला सही ऑफ़सेट चाहिए था, न कि वह ऑफ़सेट जो शेड्यूल करने के दिन लागू था।
दिखने वाला बदलाव था शेड्यूलिंग की कम गलतियाँ और किसी के लिए बेतुके समय पर पड़ी मीटिंग को लेकर माफ़ी वाले कम संदेश। कम दिखने वाला बदलाव यह था कि टीम में अब किसी को चार देशों के डेलाइट सेविंग कार्यक्रम याद नहीं रखने पड़ते थे, जो पहले सचमुच किसी की अनौपचारिक, बिना वेतन की ज़िम्मेदारी थी।
इस तरह का समाधान जितनी आसानी से बड़े पैमाने पर चलता है, उतनी ही आसानी से छोटे पैमाने पर भी। बारह लोगों की टीम और हज़ार लोगों की कंपनी की मूल समस्या एक ही है, बस मात्रा अलग है, और लुकअप की जटिलता किसी भी तरह से नहीं बदलती, सिर्फ़ यह बदलता है कि उसे कितनी बार कॉल किया जाता है। छोटी टीम के लिए उपयोग किसी कुंजी के साथ मिलने वाले मुफ़्त दैनिक कोटा के अंदर आराम से रहा, क्योंकि दर्जन भर लोगों के समय क्षेत्र कुछ बार निकालना हर दिन उपलब्ध 2,500 मुफ़्त अनुरोधों के सामने बहुत छोटा काम है।
समय क्षेत्र से जुड़े बग आम तौर पर तब तक दिखाई नहीं देते जब तक वे कोई असली समस्या न पैदा कर दें, और तब तक नुकसान एक छूटी हुई मीटिंग या उलझे हुए ग्राहक के रूप में हो चुका होता है। मूल डेटा स्रोत को एक बार ठीक कर देने से आगे के लिए इस पूरी श्रेणी की त्रुटि खत्म हो जाती है। एंडपॉइंट का दस्तावेज़ /docs/timezone-lookup/ पर है।