डेलाइट सेविंग मानने वाले ज़ोन में साल में दो बार घड़ी के साथ कुछ अजीब होता है जिसका ज़्यादातर सॉफ़्टवेयर कभी ध्यान नहीं रखता। जब घड़ियाँ आगे बढ़ती हैं, तो स्थानीय समय का एक घंटा बस मौजूद ही नहीं होता, इसलिए उस तारीख पर "सुबह 2:30 बजे" जैसा टाइमस्टैम्प असल में कभी हुआ ही नहीं। जब घड़ियाँ पीछे जाती हैं, तो एक घंटा दो बार आता है, इसलिए "सुबह 1:30 बजे" एक बार बदलाव से पहले और एक बार उसके बाद हुआ, और बिना किसी और जानकारी के सिर्फ़ स्थानीय टाइमस्टैम्प यह नहीं बता सकता कि किसकी बात हो रही है।
यह कोई दुर्लभ एज केस नहीं है जो सिर्फ़ अनोखे उपयोगों के लिए मायने रखता हो। यह एक नियमित कैलेंडर घटना है जो डेलाइट सेविंग इस्तेमाल करने वाले हर ज़ोन में हर साल दोहराई जाती है, और यह चुपचाप हर उस कोड को तोड़ देती है जो स्थानीय समय को हमेशा सुपरिभाषित मानता है। जो शेड्यूलिंग सिस्टम बुकिंग के पल का UTC ऑफ़सेट स्टोर किए बिना सिर्फ़ "इसे सुबह 1:45 बजे के लिए बुक करें" स्टोर करता है, वह महीनों बाद यह नहीं जान सकता कि अगर बुकिंग बदलाव वाली रात पड़ती है तो दोनों में से कौन-सा सुबह 1:45 बजे मतलब था।
सबसे सुरक्षित तरीका यह है कि अंदरूनी तौर पर हर जगह टाइमस्टैम्प UTC में स्टोर करें और सिर्फ़ दिखाने के लिए स्थानीय समय में बदलें। UTC में न डेलाइट सेविंग है न कोई अस्पष्टता, इसलिए एक बार किसी पल को इस तरह दर्ज कर लिया गया, तो बाद में स्थानीय घड़ी के नियमों के साथ कुछ भी हो, वह सही बना रहता है। उपयोगकर्ता के स्थानीय समय क्षेत्र में सिर्फ़ उसे दिखाते समय बदलें, उस खास पल पर उस ज़ोन के मौजूदा नियमों का उपयोग करके, और ठीक इसीलिए एक बार ऑफ़सेट कैश करके उसे दोबारा इस्तेमाल करने के बजाय ऐसा समय क्षेत्र लुकअप इस्तेमाल करना उचित है जो सिर्फ़ लोकेशन नहीं, बल्कि समय का एक खास पल भी स्वीकार करता है।
अगर आप कुछ भी ऐसा बनाते हैं जो इवेंट शेड्यूल या लॉग करता है, तो स्पष्ट रूप से टेस्ट करने लायक एज केस हैं: स्प्रिंग-फ़ॉरवर्ड बदलाव के दौरान अस्तित्वहीन घंटे के लिए की गई बुकिंग, फ़ॉल-बैक बदलाव के दोहराए गए घंटे के दौरान का टाइमस्टैम्प, और ऐसा शेड्यूल किया गया इवेंट जिसकी तारीख उसके बनने और होने के बीच किसी बदलाव को पार करती है। इनमें से कोई भी काल्पनिक नहीं है। ये हर साल एक तय, अनुमानित कार्यक्रम पर होते हैं, और डेवलपमेंट के दौरान इन्हें एक बार टेस्ट करना किसी ऐसी मीटिंग के बारे में सपोर्ट टिकट डीबग करने से कहीं सस्ता है जो एक घंटा खिसकी हुई लगी।
अगर आपके सिस्टम को सिर्फ़ ज़ोन नाम के बजाय किसी खास पल का सही ऑफ़सेट चाहिए, तो उसे किसी कैश किए गए मान से निकालने के बजाय सीधे माँगें। My Geocode का समय क्षेत्र लुकअप एक खास पल स्वीकार करता है और उसी तारीख के डेलाइट सेविंग नियम लागू करता है, इसलिए लौटाया गया ऑफ़सेट बदलाव के ठीक किनारे पर भी सही होता है।