09 जन॰ 2025·8 मिनट पढ़ने में

डेलाइट सेविंग टाइम बग्स: टाइमस्टैम्प और रिपोर्ट के नियम

Q: Why can’t I store just a UTC offset instead of a time zone name?

An offset like `-05:00` only describes the difference from UTC at one moment and doesn’t include DST rules or history. An IANA time zone like `America/New_York` carries the full rule set, so conversions stay correct for different dates.

डेलाइट सेविंग टाइम बग्स से बचने के व्यावहारिक नियम: टाइमस्टैम्प्स UTC में रखें, लोकल समय सही दिखाएँ, और ऐसी रिपोर्ट बनाएं जो उपयोगकर्ता सत्यापित कर सकें और भरोसा कर सकें।

सामान्य उत्पादों में ये बग क्यों होते हैं

टाइम बग्स इसलिए दिखते हैं क्योंकि लोग UTC में नहीं जीते—वे स्थानीय समय के अनुसार जीते हैं, और स्थानीय समय आगे कूद सकता है, पीछे जा सकता है, या वर्षों में नियम बदल सकते हैं। एक ही क्षण को दो अलग‑अलग उपयोगकर्ता अलग क्लॉक पर देख सकते हैं। और खराब बात यह है कि वही स्थानीय क्लॉक समय दो अलग वास्तविक क्षणों की ओर इशारा कर सकता है।

डेलाइट सेविंग टाइम (DST) बग्स अक्सर साल में सिर्फ दो बार ही दिखते हैं, इसलिए ये छूट जाते हैं। डेवलपमेंट में सब कुछ सही लगता है, फिर असली ग्राहक स्विच वाले वीकेंड पर कोई अपॉइंटमेंट बुक करता है, टाइमशीट भरता है, या रिपोर्ट चेक करता है और कुछ गलत महसूस होता है।

टीम्स आमतौर पर कुछ पैटर्न देखती हैं: एक "मिसिंग घंटा" जहाँ शेड्यूल किए आइटम गायब हो जाते हैं या शिफ्ट होते हैं, एक डुप्लिकेट घंटा जहाँ लॉग या अलर्ट डबल दिखते हैं, और रोजाना के टोटल्स जो इस वजह से ड्रीफ़्ट करते हैं क्योंकि किसी दिन की अवधि 23 या 25 घंटे हो गई।

यह सिर्फ डेवलपर की समस्या नहीं है। सपोर्ट टिकट आते हैं जैसे "आपकी ऐप ने मेरी मीटिंग का समय बदल दिया।" फाइनेंस mismatched दैनिक राजस्व देखता है। ऑप्स सोचता है कि रातभर जॉब्स दो बार क्यों चले या स्किप क्यों हुए। यहां तक कि “created today” फ़िल्टर भी अलग‑अलग क्षेत्रों के उपयोगकर्ताओं के बीच असहमत हो सकते हैं।

लक्ष्य साधारण और भरोसेमंद है: समय को इस तरह स्टोर करें कि उसका अर्थ कभी न खोए, स्थानीय समय इंसानों की उम्मीद के मुताबिक दिखाएं, और रिपोर्ट्स बनाएं जो अजीब दिनों पर भी सच्ची रहें। जब आप ऐसा करेंगे, तो बिजनेस का हर हिस्सा नंबरों पर भरोसा कर सकेगा।

आप कस्टम कोड से बना रहे हों या किसी प्लेटफ़ॉर्म जैसे AppMaster का उपयोग कर रहे हों—नियम वही होते हैं। आप उन टाइमस्टैम्प्स को चाहते हैं जो मूल क्षण को सुरक्षित रखें, साथ में पर्याप्त संदर्भ (जैसे उपयोगकर्ता का समय क्षेत्र) ताकि बताया जा सके कि उस क्षण पर उनके क्लॉक पर क्या दिख रहा था।

समय का एक साधारण मॉडल

अधिकांश DST बग्स इसलिए होते हैं क्योंकि हम “एक क्षण” और “क्लॉक पर दिखने वाला समय” को मिला देते हैं। इन विचारों को अलग रखें तो नियम बहुत सरल हो जाते हैं।

कुछ शब्दों की परिभाषा:

Timestamp: समयरेखा पर एक सटीक क्षण (जहां आप हैं उससे स्वतंत्र)।
UTC: एक वैश्विक संदर्भ घड़ी, जिसका उपयोग टाइमस्टैम्प्स को लगातार प्रस्तुत करने के लिए होता है।
Local time: दीवार क्लॉक पर दिखने वाला समय (उदाहरण: New York में सुबह 9:00)।
Offset: किसी खास क्षण पर UTC से फर्क, जैसे +02:00 या -05:00।
Time zone: नियमों का एक नामित सेट जो हर तारीख के लिए ऑफ़सेट तय करता है, जैसे America/New_York।

एक ऑफ़सेट और टाइम ज़ोन एक जैसे नहीं होते। -05:00 सिर्फ एक क्षण पर UTC से अंतर बताता है। यह नहीं बताता कि क्या वो जगह गर्मियों में -04:00 पर जाती है या आने वाले साल में कानून बदलेंगे। एक टाइम ज़ोन नाम ये सब बताता है क्योंकि इसमें नियम और इतिहास शामिल होते हैं।

DST ऑफ़सेट बदलता है, न कि मूल टाइमस्टैम्प। घटना वही क्षण पर हुई थी; सिर्फ स्थानीय क्लॉक का लेबल बदलता है।

दो घटनाएँ सबसे ज्यादा उलझन पैदा करती हैं:

Spring skip: क्लॉक आगे कूदता है, इसलिए कुछ स्थानीय समय अस्तित्व में नहीं आते (उदाहरण: 2:30 AM मौजूद नहीं हो सकता)।
Fall repeat: क्लॉक एक घंटा दोहराता है, इसलिए वही स्थानीय समय दो बार हो सकता है (उदाहरण: 1:30 AM अस्पष्ट हो सकता है)।

अगर सपोर्ट टिकट fall‑repeat के दौरान “1:30 AM” पर बना है, तो आपको इवेंट्स को सही क्रम में समझने के लिए टाइम ज़ोन और सटीक क्षण (UTC टाइमस्टैम्प) चाहिए होगा।

डेटा नियम जो ज्यादातर समस्याओं को रोकते हैं

अधिकांश DST बग्स एक फ़ॉर्मेटिंग समस्या नहीं, बल्कि डेटा समस्या के रूप में शुरू होते हैं। अगर स्टोर किया हुआ मान अस्पष्ट है, तो हर स्क्रीन और रिपोर्ट बाद में अनुमान लगाने लगेगी, और वे अनुमान मेल नहीं खाएंगे।

नियम 1: वास्तविक इवेंट्स को एक absolute क्षण (UTC) के रूप में स्टोर करें

अगर कुछ एक सटीक क्षण पर हुआ (भुगतान कैप्चर हुआ, टिकट का जवाब आया, शिफ्ट शुरू हुआ), तो टाइमस्टैम्प UTC में स्टोर करें। UTC आगे‑पीछे नहीं होती, इसलिए DST बदलावों में भी वह स्थिर रहती है।

उदाहरण: न्यूयॉर्क का एक सपोर्ट एजेंट क्लॉक बदलने वाले दिन स्थानीय समय 9:15 AM पर रिप्लाई करता है। UTC क्षण स्टोर करने से वह रिप्लाई लंदन में उस थ्रेड को बाद में देखने पर सही क्रम में रहेगा।

नियम 2: टाइम ज़ोन संदर्भ IANA टाइम ज़ोन ID के रूप में रखें

जब आपको समय इंसानी तौर पर दिखाना हो, तो आपको उपयोगकर्ता या स्थान का टाइम ज़ोन जानना होगा। इसे America/New_York या Europe/London जैसे IANA टाइम ज़ोन ID के रूप में स्टोर करें, न कि “EST” जैसे अस्पष्ट लेबल के रूप में। संक्षेप में मिलने वाले नाम अलग‑अलग चीज़ें बता सकते हैं, और सिर्फ ऑफ़सेट DST नियमों को नहीं पकड़ता।

सरल पैटर्न: इवेंट समय UTC में, और उपयोगकर्ता/ऑफिस/स्टोर/डिवाइस के साथ अलग tz_id फील्ड।

नियम 3: सिर्फ तारीख वाले मानों को date के रूप में स्टोर करें, timestamp नहीं

कुछ मान क्षण नहीं होते—जैसे जन्मदिन, “5 तारीख को नवीनीकरण”, या “इनवॉइस की ड्यू डेट” अक्सर डेट‑ओनली फ़ील्ड होने चाहिए। अगर आप उन्हें टाइमस्टैम्प के रूप में स्टोर करेंगे, तो टाइम ज़ोन कन्वर्ज़न उन्हें पिछले या अगले दिन में बदल सकते हैं।

नियम 4: स्थानीय समय को zone संदर्भ के बिना साधारण स्ट्रिंग के रूप में कभी स्टोर न करें

“2026-03-08 02:30” या “9:00 AM” जैसे मान बिना टाइम ज़ोन के स्टोर करने से बचें। DST ट्रांज़िशन के दौरान ये अस्पष्ट (दो बार होते) या असंभव (स्किप) हो सकते हैं।

अगर आपको स्थानीय इनपुट स्वीकार करना ही है, तो लोकल वैल्यू और टाइम ज़ोन ID दोनों स्टोर करें, और वास्तविक इवेंट क्षण के लिए UTC में कन्वर्ट करें।

विभिन्न रिकॉर्ड प्रकारों के लिए क्या स्टोर करना चाहिए

कई DST बग्स इसलिए होते हैं क्योंकि एक रिकॉर्ड टाइप को दूसरे की तरह माना जाता है। एक ऑडिट लॉग एंट्री, एक कैलेंडर मीटिंग, और एक पेरोल कटऑफ—सभी “तारीख और समय” जैसे दिखते हैं, पर उन्हें सच्चा रखने के लिए अलग डेटा चाहिए।

पिछली घटनाओं (जो पहले हो चुकी हैं) के लिए: एक सटीक क्षण, आम तौर पर UTC टाइमस्टैम्प स्टोर करें। अगर आपको बाद में दिखाना हो कि उपयोगकर्ता ने किस तरीके से इसे देखा था, तो इवेंट के समय उपयोगकर्ता का टाइम ज़ोन भी स्टोर करें (IANA ID जैसे America/New_York, सिर्फ “EST” नहीं)। इससे आप वही स्क्रीन फिर से बना पाएंगे भले ही उपयोगकर्ता बाद में अपना प्रोफ़ाइल टाइम ज़ोन बदल दे।

शेड्यूलिंग के लिए (वो चीज़ें जो स्थानीय वॉल‑क्लॉक समय पर होनी चाहिए): इच्छित स्थानीय दिनांक और समय साथ में tz_id स्टोर करें। इसे UTC में कन्वर्ट कर के मूल लोकल वैल्यू फेंक न दें। “March 10 at 09:00 in Europe/Berlin” ही उपयोगकर्ता का इरादा है। UTC एक व्युत्पन्न मान है जो नियम बदलने पर बदल सकता है।

परिवर्तन सामान्य हैं: लोग यात्रा करते हैं, ऑफिसेस relocates होते हैं, कंपनियों की पॉलिसी बदलती है। ऐतिहासिक रिकॉर्ड्स के लिए, जब उपयोगकर्ता अपना प्रोफ़ाइल टाइम ज़ोन बदलें तो पुराने समय को दोबारा न लिखें। भविष्य के शेड्यूल्स के लिए तय करें कि शेड्यूल उपयोगकर्ता के साथ चलता है (यात्रा‑अनुकूल) या एक फिक्स्ड स्थान के साथ (ऑफिस‑अनुकूल), और उस स्थान का टाइम ज़ोन स्टोर करें।

लेगेसी डेटा जिसमें केवल लोकल टाइमस्टैम्प है, मुश्किल होता है। अगर आप स्रोत टाइम ज़ोन जानते हैं तो उसे अटैच करें और पुराने समय को लोकल मान कर ट्रिट करें। अगर नहीं जानते, तो उसे “floating” के रूप में मार्क करें और रिपोर्ट्स में ईमानदार रहें (उदा., स्टोर किया हुआ मान बिना कन्वर्ज़न के दिखाएं)। ऐसे मामलों को अलग फील्ड्स में मॉडल करने से स्क्रीन और रिपोर्ट गलती से उन्हें मिला नहीं पाएंगी।

चरण‑दर‑चरण: टाइमस्टैम्प्स सुरक्षति तरीके से स्टोर करना

Make time rules repeatable

Turn your DST checklist into reusable components your team can apply to every feature.

Try AppMaster

DST बग्स रोकने के लिए, समय के लिए एक अस्पष्ट सिस्टम‑ऑफ‑रिकॉर्ड चुनें और फिर केवल तब कन्वर्ट करें जब उसे लोगों को दिखाया जाए।

अपनी टीम के लिए नियम लिखें: डेटाबेस में सभी टाइमस्टैम्प UTC हैं। इसे डॉक्यूमेंट्स और कोड‑कमेंट्स में रखें। यह वही निर्णय है जो अनजाने में बाद में उल्टा किया जा सकता है।

एक व्यवहारिक स्टोरेज पैटर्न:

सिस्टम‑ऑफ‑रिकॉर्ड के रूप में UTC चुनें और फील्ड्स के नाम स्पष्ट रखें (उदा., created_at_utc).
सही फील्ड्स जोड़ें: एक इवेंट टाइम UTC में (उदा., occurred_at_utc) और जब लोकल संदर्भ महत्वपूर्ण हो तो tz_id (IANA टाइम ज़ोन ID) रखें।
इनपुट लेते समय लोकल दिनांक‑समय और tz_id एक साथ कलेक्ट करें, फिर बाउंडरी (API या फॉर्म सबमिट) पर एक बार UTC में कन्वर्ट करें। कई लेयर्स में बार‑बार कन्वर्ट न करें।
स्टोर और क्वेरी UTC में करें। लोकल समय केवल एजेज़ पर (UI, ईमेल, एक्सपोर्ट) कन्वर्ट करें।
हाई‑स्टेक एक्शन्स (पेमेंट्स, कंप्लायंस, शेड्यूलिंग) के लिए, जो आपने रिसीव किया वह भी लॉग करें (मूल लोकल स्ट्रिंग, tz_id, और कैल्क्युलेटेड UTC)। यह विवादों पर ऑडिट‑ट्रेल देता है।

उदाहरण: उपयोगकर्ता America/Los_Angeles में “Nov 5, 9:00 AM” शेड्यूल करता है। आप occurred_at_utc = 2026-11-05T17:00:00Z और tz_id = America/Los_Angeles स्टोर करते हैं। भले ही बाद में DST नियम बदल जाएँ, आप समझा पाएँगे कि उपयोगकर्ता ने क्या मतलब किया और आपने क्या स्टोर किया।

अगर आप PostgreSQL में मॉडल कर रहे हैं (या विज़ुअल डेटा मॉडलिंग टूल्स के जरिए), तो कॉलम टाइप्स स्पष्ट और सुसंगत रखें और ऐप को हर बार UTC लिखنے पर मजबूर करें।

उपयोगकर्ताओं के समझने योग्य स्थानीय समय दिखाना

Multi-time-zone workflows

Build internal tools like ticketing or timesheets that work across offices and regions.

Start a Project

ज्यादातर DST बग UI में ही दिखते हैं, न कि डेटाबेस में। लोग वही पढ़ते हैं जो आप दिखाते हैं, उसे मैसेज में कॉपी करते हैं और उसी के अनुसार प्लान करते हैं। अगर स्क्रीन अस्पष्ट है, उपयोगकर्ता गलत मान लेंगे।

जब समय मायने रखता है (बुकिंग, टिकट, अपॉइंटमेंट, डिलीवरी विंडोज), तो इसे रसीद की तरह दिखाएँ: पूरा, विशिष्ट और लेबल किया हुआ।

डिस्प्ले को पहले से अनुमान्य रखें:

तारीख + समय + टाइम ज़ोन दिखाएँ (उदाहरण: “Mar 10, 2026, 9:30 AM America/New_York”).
टाइम ज़ोन लेबल समय के पास रखें, सेटिंग्स में छुपाएँ नहीं।
अगर आप सापेक्ष टेक्स्ट दिखाते हैं (“2 घंटे में”), तो पास में सटीक टाइमस्टैम्प भी रखें।
साझा आइटम्स के लिए, विचार करें दोनों—व्यूअर का लोकल समय और इवेंट का टाइम ज़ोन—दिखाने का।

DST एज केसेस के लिए स्पष्ट व्यवहार चाहिए। अगर आप यूज़र्स को किसी भी समय टाइप करने की अनुमति देते हैं, तो अंततः आप ऐसा समय स्वीकार करेंगे जो कभी मौजूद नहीं होता या दो बार होता।

Spring-forward (मिसिंग टाइम्स): अमान्य चयन ब्लॉक करें और अगला मान्य समय सुझाएँ।
Fall-back (अस्पष्ट टाइम्स): ऑफ़सेट या स्पष्ट विकल्प दिखाएँ (उदाहरण: “1:30 AM UTC-4” बनाम “1:30 AM UTC-5”)।
मौजूदा रिकॉर्ड एडिट करना: मौलिक इंस्टेंट को बनाए रखें भले ही फॉर्मैट बदल जाए।

उदाहरण: बर्लिन का एक सपोर्ट एजेंट न्यूयॉर्क के ग्राहक के साथ “Nov 3, 1:30 AM” कॉल शेड्यूल करता है। Fall‑back के दौरान, न्यूयॉर्क में वह समय दो बार आता है। अगर UI में लिखा हो “Nov 3, 1:30 AM (UTC-4)”, तो भ्रम दूर हो जाता है।

रिपोर्ट्स बनाएं जो झूठ न बोलें

रिपोर्ट्स तब भरोसा खो देते हैं जब वही डेटा देखने वाले के अनुसार अलग‑अलग टोटल देता है। DST बग्स से बचने के लिए यह तय करें कि हर रिपोर्ट असल में किस चीज़ को समूह बना रही है, और फिर उसी पर बने रहें।

पहले यह तय करें कि किसी रिपोर्ट के लिए “दिन” का मतलब क्या है। सपोर्ट टीम अक्सर ग्राहक के स्थानीय दिन में सोचती है। फाइनेंस को अकाउंट के लीगल टाइम ज़ोन की जरूरत होती है। कुछ टेक्निकल रिपोर्ट्स UTC‑दिन में सुरक्षित रहती हैं।

लोकल दिन के हिसाब से ग्रुपिंग DST के पास काफी बदलाव लाती है। Spring‑forward दिन पर एक लोकल घंटा गायब हो जाता है। Fall‑back दिन पर एक घंटा दोहरा जाता है। अगर आप “लोकल तारीख” से ग्रुप करते हैं बिना स्पष्ट नियम के, तो एक व्यस्त घंटा गायब, डबल या गलत दिन में दिख सकता है।

व्यावहारिक नियम: हर रिपोर्ट का एक रिपोर्टिंग टाइम ज़ोन होता है, और वह हेडर में दिखता है (उदाहरण: “All dates shown in America/New_York”)। इससे गणना अनुमान्य रहती है और सपोर्ट के पास स्पष्ट जवाब होता है।

मल्टी‑रीजन टीम्स के लिए, यह ठीक है कि लोग रिपोर्ट टाइम ज़ोन बदल सकें, पर इसे सच का अलग दृश्य माना जाना चाहिए। दो दर्शक बंद‑बंदी और DST ट्रांज़िशन के पास अलग दैनिक बकेट देख सकते हैं—यह सामान्य है जब तक रिपोर्ट चुना हुआ ज़ोन साफ़-साफ़ दिखा रही हो।

कुछ विकल्प जो आश्चर्य कम कर देते हैं:

रिपोर्ट दिवस सीमा परिभाषित करें (यूज़र ज़ोन, अकाउंट ज़ोन, या UTC) और इसका दस्तावेजीकरण करें।
एक रन के लिए एक टाइम ज़ोन उपयोग करें, और उसे डेट रेंज के पास दिखाएँ।
दैनिक टोटल्स के लिए, चुने गए ज़ोन में लोकल तारीख से ग्रुप करें (UTC तारीख से नहीं)।
घंटा‑वार चार्ट्स के लिए, fall‑back दिनों पर दोहराए गए घंटों को लेबल करें।
अवधि (durations) के लिए, elapsed seconds स्टोर और जोड़ें, फिर डिस्प्ले के लिए फॉर्मैट करें।

Durations पर विशेष ध्यान दें। एक "2‑घंटे की शिफ्ट" जो fall‑back को पार करती है, दीवार‑क्लॉक पर 3 घंटे लग सकती है पर वास्तविकता में 2 घंटे elapsed हो सकते हैं अगर व्यक्ति ने 2 घंटे काम किया। उपयोगकर्ता किस अर्थ की उम्मीद करते हैं यह तय करें, और फिर सुसंगत राउंडिंग लागू करें (उदा., जोड़ने के बाद राउंड करें, न कि प्रति पंक्ति)।

सामान्य जाल और उनसे बचने के तरीके

Reports that stay honest

Make daily totals consistent by choosing a reporting time zone and applying it everywhere.

Create Report

DST बग्स "कठिन गणित" नहीं हैं। वे छोटे‑छोटे अनुमान से आते हैं जो समय के साथ पैर पसार लेते हैं।

क्लासिक गलती है लोकल टाइमस्टैम्प को UTC के रूप में सेव कर देना। सब कुछ ठीक दिखता है जब तक कोई दूसरे टाइम ज़ोन वाला व्यक्ति रिकॉर्ड खोलता है और वह चुपचाप शिफ्ट हो जाता है। सुरक्षित नियम सरल है: एक इंस्टेंट (UTC) स्टोर करें और साथ में सही संदर्भ (उपयोगकर्ता या स्थान टाइम ज़ोन) रखें जब रिकॉर्ड का लोकल अर्थ महत्वपूर्ण हो।

एक और सामान्य स्रोत फिक्स्ड ऑफ़सेट्स का उपयोग है जैसे -05:00। ऑफ़सेट्स DST बदलावों या ऐतिहासिक नियमों के बारे में नहीं जानते। वास्तविक IANA टाइम ज़ोन IDs (जैसे America/New_York) का उपयोग करें ताकि आपके सिस्टम में तारीख के लिए सही नियम लागू हों।

कुछ आदतें कई “डबल‑शिफ्ट” आश्चर्य रोकती हैं:

एजेज़ पर ही कन्वर्ट करें: इनपुट एक बार पार्स करें, एक बार स्टोर करें, और डिस्प्ले पर ही कन्वर्ट करें।
“इंस्टेंट” फील्ड्स (UTC) और “वॉल‑क्लॉक” फील्ड्स (लोकल दिनांक/समय) के बीच स्पष्ट रेखा रखें।
लोकल व्याख्या पर निर्भर रिकॉर्ड्स के साथ tz_id स्टोर करें।
सर्वर टाइम ज़ोन को अप्रासंगिक बनाएं—हमेशा UTC पढ़ें और लिखें।
रिपोर्ट्स के लिए रिपोर्ट टाइम ज़ोन परिभाषित करें और UI में दिखाएँ।

छिपे हुए कन्वर्ज़न से भी सावधान रहें। एक आम पैटर्न: यूज़र का लोकल समय UTC में पार्स किया जाता है, फिर बाद में कोई UI लाइब्रेरी मान लेती है कि वैल्यू लोकल है और फिर से कन्वर्ट कर देती है। परिणाम एक‑घंटे का कूद होता है जो केवल कुछ उपयोगकर्ताओं और कुछ तारीखों पर दिखाई देता है।

अंत में, क्लाइंट डिवाइस का टाइम ज़ोन बिलिंग या कंप्लायंस के लिए उपयोग न करें। किसी यात्री का फोन ट्रिप के बीच ज़ोन बदल सकता है। इसके बजाय व्यावसायिक नियम (जैसे ग्राहक का अकाउंट टाइम ज़ोन या साइट लोकेशन) पर रिपोर्ट बेस करें।

परीक्षण: कुछ केस जो सबसे अधिक बग पकड़ते हैं

अधिकांश टाइम बग्स साल में सिर्फ कुछ दिनों पर दिखते हैं, इसलिए QA में छूट जाते हैं। हल है सही पलों का परीक्षण करना और इन टेस्ट्स को पुनरावृत्त करने योग्य बनाना।

एक DST‑observing टाइम ज़ोन चुनें (उदा., America/New_York या Europe/Berlin) और दोनों ट्रांज़िशन दिनों के लिए टेस्ट लिखें। फिर एक ऐसा ज़ोन चुनें जो कभी DST नहीं इस्तेमाल करता (उदा., Asia/Singapore या Africa/Nairobi) ताकि आप स्पष्ट अंतर देख सकें।

जो 5 टेस्ट हमेशा रखें

Spring‑forward दिन: यह सत्यापित करें कि मिसिंग घंटा शेड्यूल नहीं किया जा सकता और कन्वर्ज़न ऐसी कोई टाइम नहीं बना रहे जो अस्तित्व में नहीं है।
Fall‑back दिन: डुप्लिकेट घंटे का परीक्षण करें—दो अलग UTC क्षणों का लोकल समय समान दिखता है। सुनिश्चित करें कि लॉग्स और एक्सपोर्ट उन्हें अलग रख पाते हैं।
मध्यरात्रि पार करने वाले स्पैन: ऐसा इवेंट बनाएं जो स्थानीय समय में मध्यरात्रि पार करे और पुष्टि करें कि सॉर्टिंग और ग्रुपिंग UTC में भी सही काम करें।
Non‑DST कंट्रास्ट: एक नॉन‑DST ज़ोन में कन्वर्ज़न दोहराएँ और सुनिश्चित करें कि परिणाम एक ही तिथियों के दौरान स्थिर रहें।
रिपोर्टिंग स्नैपशॉट्स: महीने‑एंड और DST वीकेंड के आसपास रिपोर्ट्स के अपेक्षित टोटल्स सहेजें और हर बदलाव के बाद आउटपुट की तुलना करें।

एक ठोस परिदृश्य

कल्पना करें सपोर्ट टीम fall‑back रात में “01:30” फॉलो‑अप शेड्यूल करती है। अगर आपकी UI सिर्फ दिखाई देने वाला लोकल टाइम स्टोर करती है, तो आप नहीं बता पाएँगे कि किस “01:30” का मतलब था। अच्छा टेस्ट दोनों UTC टाइमस्टैम्प बनाता है जो स्थानीय रूप से 01:30 बनते हैं और पुष्टि करता है कि ऐप उन्हें अलग रखता है।

ये टेस्ट जल्दी दिखा देते हैं कि आपका सिस्टम सही तथ्य स्टोर कर रहा है (UTC इंस्टेंट, tz_id, और कभी‑कभी मूल लोकल टाइम) और क्लॉक्स बदलते समय रिपोर्ट्स ईमानदार रहती हैं या नहीं।

शिप करने से पहले जल्दी‑सी चेकलिस्ट

Add time you can prove

Create an audit trail with stored UTC, zone ID, and original input for disputed timestamps.

Get Started

DST बग्स इसलिए छूट जाते हैं क्योंकि ऐप अधिकतर दिनों में सही दिखता है। कभी भी कुछ वितरित करने से पहले यह चेकलिस्ट उपयोग करें, खासकर अगर आप समय दिखाते हैं, तारीख से फ़िल्टर करते हैं, या रिपोर्ट एक्सपोर्ट करते हैं।

हर रिपोर्ट के लिए एक रिपोर्टिंग टाइम ज़ोन चुनें (उदा., “Business HQ time” या “User’s time”)। इसे रिपोर्ट हेडर में दिखाएँ और टेबल्स, टोटल्स और चार्ट्स में सुसंगत रखें।
हर “पल” को UTC में स्टोर करें (created_at, paid_at, message_sent_at)। संदर्भ चाहिए तो IANA टाइम ज़ोन ID स्टोर करें।
DST लागू हो सकता है ऐसे मामलों में "UTC-5" जैसे फिक्स्ड ऑफ़सेट्स से कैलकुलेट न करें। तारीख के नियमों के अनुसार टाइम ज़ोन कन्वर्ज़न करें।
हर जगह समय को स्पष्ट रूप से लेबल करें (UI, ईमेल, एक्सपोर्ट)। तारीख, समय और टाइम ज़ोन शामिल करें ताकि स्क्रीनशॉट और CSV मिसरीड न हों।
एक छोटा DST टेस्ट सेट रखें: स्प्रिंग जंप से ठीक पहले एक टाइमस्टैम्प, स्प्रिंग जंप के ठीक बाद एक, और fall‑repeat घंटे के आसपास भी कुछ टाइमस्टैम्प्स।

वास्तविकता‑जांच: अगर न्यूयॉर्क का एक सपोर्ट मैनेजर “Sunday” पर बनाए गए टिकट्स का एक्सपोर्ट निकालता है और लंदन का एक साथी फाइल खोलता है, तो दोनों को यह पता होना चाहिए कि टाइमस्टैम्प किस टाइम ज़ोन का प्रतिनिधित्व कर रहे हैं—और उन्हें अनुमान नहीं लगाना चाहिए।

उदाहरण: अलग‑अलग टाइम ज़ोन्स में एक वास्तविक सपोर्ट वर्कफ़्लो

Stop DST bugs early

Build a time-safe data model with UTC timestamps and IANA zones from day one.

Try AppMaster

एक ग्राहक न्यूयॉर्क में एक सपोर्ट टिकट सबमिट करता है उस हफ्ते जब US ने daylight saving शुरू कर दिया है पर UK ने अभी नहीं किया है। आपकी सपोर्ट टीम लंदन में है।

मार्च 12 को ग्राहक ने न्यूयॉर्क में 09:30 स्थानीय समय पर टिकट सबमिट किया। उस क्षण 13:30 UTC है, क्योंकि न्यूयॉर्क अब UTC‑4 है। लंदन का एक एजेंट 14:10 लंदन समय पर रिप्लाई करता है, जो उस हफ्ते 14:10 UTC है (लंदन अभी UTC+0 है)। रिप्लाई टिकट बनाये जाने के 40 मिनट बाद आया।

अगर आप केवल लोकल समय स्टोर करते हैं और टाइम ज़ोन नहीं रखते तो यह कैसे टूटेगा:

आप “09:30” और “14:10” को साधारण टाइमस्टैम्प के रूप में सेव करते हैं।
बाद में एक रिपोर्ट जॉब मान लेता है कि “New York हमेशा UTC‑5 है” (या सर्वर का टाइम ज़ोन इस्तेमाल करता है)।
वह 09:30 को 14:30 UTC के रूप में कन्वर्ट कर देता है, जबकि सही मान 13:30 UTC था।
आपका SLA क्लॉक 1 घंटे ऑफ़ हो जाता है और एक टिकट जो 2‑घंटे SLA में था, लेट दिख सकता है।

सुरक्षित मॉडल में UI और रिपोर्टिंग सुसंगत रहते हैं। इवेंट समय को UTC टाइमस्टैम्प के रूप में स्टोर करें, और संबंधित IANA टाइम ज़ोन ID स्टोर करें (उदा., ग्राहक के लिए America/New_York, एजेंट के लिए Europe/London). UI में उसी UTC क्षण को दर्शक के टाइम ज़ोन में दिखाएँ, उस तारीख के नियमों का उपयोग करते हुए।

साप्ताहिक रिपोर्ट के लिए एक स्पष्ट नियम चुनें जैसे “ग्रुपिंग कस्टमर लोकल डे के अनुसार।” America/New_York में दिन की सीमाएँ (midnight to midnight) कंप्यूट करें, फिर उन सीमाओं को UTC में कन्वर्ट करें और उन सीमाओं के भीतर टिकट्स गिनें। इससे संख्याएँ DST हफ्तों में भी स्थिर रहेंगी।

अगले कदम: अपने ऐप में टाइम हैंडलिंग को सुसंगत बनाना

अगर आपके प्रोडक्ट को DST बग्स ने प्रभावित किया है, तो सबसे तेज़ रास्ता कुछ नियम लिखना और उन्हें हर जगह लागू करना है। “लगभग सुसंगत” ही वह जगह होती है जहाँ टाइम समस्याएँ रहती हैं।

नियम छोटे और विशिष्ट रखें:

Storage format: आप क्या स्टोर करते हैं (अमूमन UTC में एक इंस्टेंट) और क्या कभी न स्टोर करें (टाइम ज़ोन के बिना अस्पष्ट लोकल टाइम)।
Report time zone: किस ज़ोन का उपयोग डिफ़ॉल्ट रूप से रिपोर्ट्स करती हैं, और उपयोगकर्ता कैसे बदल सकते हैं।
UI labeling: समय के साथ क्या दिखेगा (उदा., “Mar 10, 09:00 (America/New_York)” बनाम सिर्फ “09:00”)।
Rounding rules: आप समय को कैसे बकेट करते हैं (घंटा, दिन, सप्ताह) और वे बकेट कौन से ज़ोन फॉलो करते हैं।
Audit fields: कौन से टाइमस्टैम्प्स “इवेंट हुआ” का अर्थ रखते हैं बनाम “रिकॉर्ड बनाया/अपडेट हुआ” का।

इसे लो‑रिस्क तरीके से लागू करें। पहले नए रिकॉर्ड्स ठीक करें ताकि समस्या बढ़ना बंद हो जाए। फिर ऐतिहासिक डेटा बैचों में माइग्रेट करें। माइग्रेशन के दौरान, दोनों—मूल वैल्यू (यदि उपलब्ध हो) और सामान्यीकृत वैल्यू—काफ़ी समय तक रखें ताकि रिपोर्ट्स में अंतर दिखाई दे सके।

अगर आप AppMaster (appmaster.io) का उपयोग कर रहे हैं, तो एक व्यावहारिक लाभ यह है कि आप इन नियमों को अपने डेटा मॉडल और साझा बिज़नेस लॉजिक में केंद्रीकृत कर सकते हैं: UTC टाइमस्टैम्प्स को सुसंगत रूप से स्टोर करें, उन रिकॉर्ड्स के साथ IANA टाइम ज़ोन IDs रखें जिन्हें लोकल अर्थ चाहिए, और इनपुट तथा डिस्प्ले बाउंडरी पर कन्वर्ज़न लागू करें।

एक व्यावहारिक अगला कदम एक टाइम ज़ोन‑सुरक्षित रिपोर्ट (जैसे “tickets resolved per day”) बनाना और ऊपर दिए टेस्ट केसों का उपयोग करके उसे validate करना है। अगर यह दो अलग टाइम ज़ोन्स के लिए DST स्विच हफ्ते के दौरान सही रहती है, तो आप अच्छी स्थिति में हैं।

सामान्य प्रश्न

Daylight saving time changes the local clock offset, not the actual moment an event happened. If you treat a local clock reading like it’s the same as a real instant, you’ll see “missing” times in spring and “duplicate” times in fall.

Store real events as an absolute instant in UTC, so the value never jumps when offsets change. Then convert to a viewer’s local time only when displaying it, using a real time zone ID.

An offset like -05:00 only describes the difference from UTC at one moment and doesn’t include DST rules or history. An IANA time zone like America/New_York carries the full rule set, so conversions stay correct for different dates.

Store date-only things as dates when they are not real instants, like birthdays, invoice due dates, and “renews on the 5th.” If you store them as timestamps, converting between time zones can move them to the day before or after.

“Spring-forward” creates local times that never occur, so the app should block invalid selections and nudge to the next valid time. “Fall-back” creates a repeated hour, so the UI must let the user choose which instance they mean, typically by showing the offset.

For scheduling, store the intended local date and time plus the time zone ID, because that’s the user’s intent. You can also store a derived UTC instant for execution, but don’t throw away the original local intent or you’ll lose meaning when rules change.

Pick one reporting time zone per report and make it visible, so everyone knows what “day” means. Grouping by local day can produce 23-hour or 25-hour days near DST, which is fine as long as the report clearly states the chosen zone and applies it consistently.

Convert only at the boundaries: parse input once, store once, and format once for display. Double-conversion usually happens when one layer assumes a timestamp is local and another assumes it’s UTC, causing one-hour shifts that only appear on certain dates.

Store elapsed time in seconds (or another absolute unit) and sum those values, then format the result for display. Decide whether you mean elapsed time or wall-clock time before implementing payroll, SLAs, or shift lengths, because DST nights can make wall-clock hours look longer or shorter.

Test both DST transition days in at least one DST-observing zone and compare with a non-DST zone to spot assumptions. Include cases for the missing hour, the repeated hour, events near midnight, and report bucketing, because that’s where time bugs usually hide.