शेड्यूलिंग ऐप्स में समय क्षेत्र अक्सर मीटिंग मिस होने का मुख्य कारण होते हैं। सुरक्षित डेटा मॉडल, रिकरिंग रूल्स, DST जटिलताएं और यूज़र‑फ्रेंडली कॉपी सीखें।

समय क्षेत्र छोटे गणितीय त्रुटियों को टूटी हुई वादों में बदल देते हैं। एक मीटिंग का 1 घंटे से खिसक जाना "काफी पास" नहीं होता। इससे पता चलता है कि कौन उपस्थित होता है, कौन लापरवाह दिखता है, और कौन कुछ महत्वपूर्ण मिस कर देता है। यह दो बार होने पर लोग कैलेंडर पर भरोसा करना बंद कर देते हैं और सब कुछ चैट में दुहराने लगते हैं।
मूल समस्या यह है कि मानवों के लिए समय निश्चित लगता है, लेकिन सॉफ़्टवेयर में यह निश्चित नहीं होता। लोग स्थानीय घड़ी के समय ("मेरा समय 9:00 AM") में सोचते हैं। कंप्यूटर अक्सर ऑफ़सेट ("UTC+2") के रूप में सोचते हैं जो वर्ष के दौरान बदल सकते हैं। जब आपका ऐप इन विचारों को मिला देता है, तो वह आज सही समय दिखा सकता है और अगले महीने गलत दिखा सकता है।
लक्षण भी यादृच्छिक दिखते हैं, जो चीज़ों को और बदतर बनाता है। यूज़र्स शिकायत करते हैं कि मीटिंग्स "हिल रही हैं" भले ही किसी ने कोई बदलाव न किया हो, रिमाइंडर जल्दी या देरी से फायर होते हैं, सीरीज़ में केवल कुछ उदाहरण 1 घंटे खिसक जाते हैं, इनवाइट्स अलग‑अलग डिवाइस पर अलग समय दिखाते हैं, या यात्रा के बाद डुप्लिकेट इवेंट्स दिखाई देते हैं।
सबसे ज्यादा प्रभावित वे लोग होते हैं जो शेड्यूलिंग पर निर्भर हैं: कई देशों में फैली रिमोट टीम्स, सीमा पार बुक करने वाले ग्राहक, और कोई भी जो यात्रा करता है। एक प्रोडक्ट मैनेजर न्यूयॉर्क से लंदन उड़ रहा हो सकता है और उम्मीद करेगा कि 2:00 PM मीटिंग आयोजक के टाइम ज़ोन से जुड़ी रहे, जबकि यात्र करने वाला व्यक्ति चाहता है कि वह उनकी वर्तमान स्थानीय समय के अनुसार फॉलो करे। दोनों अपेक्षाएँ वाजिब हैं। केवल एक ही सच्चा हो सकता है, इसलिए आपको स्पष्ट नियम चाहिए।
यह सिर्फ इवेंट कार्ड पर दिखने वाले समय के बारे में नहीं है। टाइम ज़ोन नियम पूरे शेड्यूलिंग सतह को छूते हैं: सिंगल इवेंट्स, रिकरिंग इवेंट्स, रिमाइंडर, इनवाइट ईमेल, और कोई भी चीज जो किसी विशेष क्षण पर ट्रिगर होती है। अगर आप हर एक के लिए नियम परिभाषित नहीं करते, तो आपका डेटा मॉडल चुपचाप वह नियम तय कर देगा, और यूज़र्स कठिन रास्ते से वह नियम जान पाएंगे।
सरल उदाहरण: एक साप्ताहिक "सोमवार 9:00 AM" स्टैंडअप मार्च में बनाया गया। अप्रैल में किसी प्रतिभागी के क्षेत्र के लिए DST बदल जाता है। अगर आपका ऐप इसे "हर 7 दिन पर एक ही UTC इंस्टैंट पर" स्टोर करता है, तो उस प्रतिभागी को अचानक यह 10:00 AM दिखेगा। अगर आपका ऐप इसे "आयोजक के टाइम ज़ोन में हर सोमवार 9:00 AM" के रूप में स्टोर करता है, तो यह 9:00 AM पर रहता है और UTC इंस्टैंट बदल जाता है। दोनों विकल्प काम कर सकते हैं, पर ऐप को लगातार और ईमानदार होना चाहिए।
अधिकांश टाइम ज़ोन बग कुछ मूल विचारों को गलत मिलाने से आते हैं। शब्दों को सही रखना आपकी UI कॉपी को भी स्पष्ट बनाता है।
UTC (Coordinated Universal Time) वैश्विक संदर्भ घड़ी है। इसे उस एकल टाइमलाइन के रूप में सोचें जिसे हर कोई साझा करता है।
एक "निरपेक्ष समय" वह विशिष्ट क्षण है उस टाइमलाइन पर, जैसे 2026-01-16 15:00:00 UTC. अगर दो लोग अलग देशों में उसी क्षण को देखें, तो उन्हें समान इंस्टैंट दिखना चाहिए, बस स्थानीय घड़ी के रूप में अलग‑अलग।
स्थानीय समय वही है जो व्यक्ति अपनी दीवार घड़ी पर देखता है, जैसे "9:00 AM"। अपने आप में यह किसी क्षण की पहचान के लिए पर्याप्त नहीं है। आपको एक स्थानीय नियम चाहिए।
ऑफ़सेट वह अंतर है UTC से किसी क्षण पर, जैसे UTC+2 या UTC-5। कई जगहों पर ऑफ़सेट वर्ष के दौरान बदलते हैं, इसलिए केवल "UTC+2" स्टोर करना जोखिमपूर्ण है।
एक टाइम ज़ोन ID असली नियम सेट है, आमतौर पर IANA नाम जैसे America/New_York या Europe/Berlin. IDs उस जोन का इतिहास और भविष्य के परिवर्तन (DST सहित) पकड़ते हैं।
व्यावहारिक अंतर:
America/New_York (जानता है कि यह कब UTC-4 बनता है)DST वह समय है जब किसी क्षेत्र में घड़ियाँ आगे या पीछे की जाती हैं, आमतौर पर एक घंटा। इसका मतलब है कि UTC ऑफ़सेट बदल जाता है।
दो DST आश्चर्यजनक बातें:
वॉल‑क्लॉक समय वही है जो उपयोगकर्ता टाइप करते हैं: "हर सोमवार 9:00 AM"। निरपेक्ष समय वह है जिसे आपका सिस्टम निष्पादित करेगा: "इस सटीक UTC क्षण पर रिमाइंडर भेजो"। रिकरिंग इवेंट अक्सर वॉल‑क्लॉक नियम के रूप में शुरू होते हैं, फिर उन्हें निरपेक्ष समय के सीरीज़ में बदला जाता है।
उपयोगकर्ता सोचते हैं कि उन्होंने "अपने टाइम ज़ोन में 9:00 AM" बुक किया। आपका डेटाबेस हो सकता है कि "2026-03-10 13:00 UTC" स्टोर कर रहा हो। दोनों सही हो सकते हैं, पर तभी जब आप यह भी याद रखें कि किस टाइम ज़ोन नियम का इरादा था।
डिवाइस भी टाइम ज़ोन बदलते हैं। लोग यात्रा करते हैं, और लैपटॉप स्वचालित रूप से ज़ोन बदल सकते हैं। अगर आपका ऐप चुपचाप एक सेव्ड "9:00 AM" को डिवाइस के नए ज़ोन के अनुसार फिर से व्याख्यायित करता है, तो यूज़र्स महसूस करेंगे कि मीटिंग "हिली" जबकि उन्होंने कुछ नहीं किया।
अधिकांश "मेरी मीटिंग हिली" बग डेटा मॉडल बग होते हैं। एक-बार की घटनाओं के लिए सबसे सुरक्षित डिफ़ॉल्ट यह है: उपयोग में एकल इंस्टेंट UTC में स्टोर करें, और केवल दिखाते समय उसे उपयोगकर्ता के स्थानीय समय में कन्वर्ट करें।
एक one-time इवेंट कुछ ऐसा है जैसे "Oct 12, 2026 at 15:00 in Berlin." वह क्षण एक बार होता है। अगर आप इसे UTC (टाइमलाइन पर एक इंस्टेंट) के रूप में स्टोर करते हैं, तो यह हमेशा उसी क्षण पर वापस मैप होगा, चाहे दर्शक कहीं भी हो।
केवल लोकल समय (जैसे "15:00") स्टोर करना तब टूटा हुआ है जब कोई इसे किसी अन्य टाइम ज़ोन से देखे, या क्रिएटर अपने डिवाइस सेटिंग बदल दे। केवल ऑफ़सेट (जैसे "+02:00") स्टोर करना बाद में टूट जाता है क्योंकि ऑफ़सेट DST के साथ बदलता है। "+02:00" कोई जगह नहीं है, यह सिर्फ एक अस्थायी नियम है।
कब आपको UTC के साथ टाइम ज़ोन ID भी स्टोर करनी चाहिए? जब भी आप परवाह करते हैं कि क्रिएटर ने क्या मतलब रखा था, सिर्फ आपने कौन सा इंस्टैंट स्टोर किया। Europe/Berlin जैसा एक zone ID डिस्प्ले, ऑडिट और सपोर्ट में मदद करता है, और यह रिकरिंग इवेंट्स के लिए अनिवार्य बन जाता है। यह आपको यह कहने देता है: "यह इवेंट 15:00 Berlin समय के रूप में बनाया गया था," भले ही Berlin का ऑफ़सेट अगले महीने बदल जाए।
एक प्रैक्टिकल रिकॉर्ड एक one-time इवेंट के लिए आम तौर पर शामिल करता है:
start_at_utc (और end_at_utc)created_at_utccreator_time_zone_id (IANA नाम)original_input (उपयोगकर्ता ने जो टेक्स्ट या फ़ील्ड डाले थे)input_offset_minutes (विकल्पिक, डिबगिंग के लिए)सपोर्ट के लिए, ये फ़ील्ड किसी अस्पष्ट शिकायत को एक स्पष्ट रिप्ले में बदल देती हैं: उपयोगकर्ता ने क्या टाइप किया, उनके डिवाइस ने कौन सा ज़ोन बताया, और आपके सिस्टम ने कौन सा इंस्टैंट स्टोर किया।
कन्वर्शन कहाँ होती है इसके प्रति कड़ा बनें। सर्वर को स्टोरेज (केवल UTC) का सोर्स ऑफ़ ट्रूथ मानें, और क्लाइंट को इरादे का सोर्स (लोकल समय प्लस एक टाइम ज़ोन ID)। लोकल समय को UTC में बनाने के लिए केवल एक बार कन्वर्ट करें, निर्माण या एडिट के समय, और बाद के पढ़ने पर स्टोर किए हुए UTC को फिर से "री‑कन्वर्ट" न करें। साइलेंट शिफ्ट अक्सर तब होते हैं जब क्लाइंट और सर्वर दोनों कन्वर्शन लागू करते हैं, या जब एक पक्ष अनुमान लगाता है बजाय कि दिए गए ज़ोन का उपयोग करने के।
अगर आप बहु क्लाइंट से इवेंट स्वीकार करते हैं, तो टाइम ज़ोन ID लॉग करें और उसे वैलिडेट करें। अगर यह गायब है, तो उपयोगकर्ता से चुनने के लिए कहें बजाय अनुमान लगाने के। वह छोटा सा प्रॉम्प्ट बाद में कई गुस्से भरे टिकट रोकता है।
जब उपयोगकर्ता बार‑बार समय "हिलता" देखते हैं, तो सामान्यतः यह इसलिए होता है क्योंकि सिस्टम के विभिन्न हिस्से समय को विभिन्न तरीकों से कन्वर्ट करते हैं।
कन्वर्शन के लिए एक जगह चुनें जो सोर्स ऑफ़ ट्रूथ हो। कई टीमें सर्वर चुनती हैं क्योंकि यह वेब, मोबाइल, ईमेल और बैकग्राउंड जॉब्स के लिए एक जैसा परिणाम गारंटी देता है। क्लाइंट फिर भी प्रीव्यू कर सकता है, पर सर्वर को फाइनल स्टोर किए गए मानों की पुष्टि करनी चाहिए।
एक रिपीटेबल पाइपलाइन अधिकांश आश्चर्य टाल देती है:
2026-03-10 09:00) और इवेंट टाइम ज़ोन को एक IANA नाम के रूप में लें (America/New_York), किसी संक्षेप जैसे "EST" के बजाय।उदाहरण: न्यूयॉर्क का होस्ट बनाता है "Tue 9:00 AM (America/New_York)." टीममेट बर्लिन में इसे "3:00 PM (Europe/Berlin)" के रूप में देखेगा क्योंकि वही UTC इंस्टैंट उनके जोन में दिख रहा है।
All-day इवेंट का अर्थ "00:00 UTC से 00:00 UTC" नहीं है। यह आमतौर पर किसी विशेष टाइम ज़ोन में एक तारीख़ रेंज होती है। All-day को date-only मान (start_date, end_date) और उस_ZONE के साथ स्टोर करें जिसका उपयोग उन तिथियों की व्याख्या के लिए हुआ था। अन्यथा, all-day इवेंट पश्चिमी ऑफ़सेट वाले उपयोगकर्ताओं के लिए एक दिन पहले शुरू होता हुआ दिखाई दे सकता है।
शिप करने से पहले वास्तविक दुनिया का टेस्ट करें: एक इवेंट बनाएं, डिवाइस टाइम ज़ोन बदलें, फिर इसे फिर से खोलें। इवेंट अभी भी वही क्षण होना चाहिए (टाइम्ड इवेंट्स के लिए) या वही लोकल तारीख़ (all-day इवेंट्स के लिए), चुपचाप शिफ्ट न हो।
अधिकांश शेड्यूलिंग बग तब दिखाई देते हैं जब कोई इवेंट रिपीट होता है। सामान्य गलती रिकरेंस को "बस तारीख आगे कॉपी कर देना" मानना है। पहले तय करें कि इवेंट किससे अँकर किया गया है:
अधिकांश कैलेंडरों (मीटिंग्स, रिमाइंडर, ऑफिस ऑवर्स) के लिए उपयोगकर्ता वॉल‑क्लॉक की उम्मीद करते हैं। "हर सोमवार 9:00 AM" आमतौर पर चुनी हुई सिटी के 9:00 AM का मतलब होता है, न कि "हमेशा के लिए वही UTC क्षण"।
रिकरेंस को प्री‑जनरेटेड टाइमस्टैम्प की सूची के रूप में न स्टोर करें; नियम और उसे व्याख्यायित करने के लिए संदर्भ स्टोर करें:
यह आपको DST को बिना "साइलेंट शिफ्ट" के संभालने में मदद करता है, और एडिट्स को पूर्वानुमानित बनाता है।
जब आपको किसी तारीख़ रेंज के लिए इवेंट चाहिए होते हैं, तो इवेंट के ज़ोन में लोकल समय में जनरेट करें, फिर हर इंस्टेंस को तुलना या स्टोरेज के लिए UTC में कन्वर्ट करें। कुंजी यह है कि लोकल शब्दों में "एक सप्ताह जोड़ें" या "अगला सोमवार" करें, न कि UTC में "+ 7 * 24 hours" करें।
एक सरल मानसिक टेस्ट: अगर उपयोगकर्ता ने बर्लिन में साप्ताहिक 9:00 AM चुना है, तो हर जनरेट किया गया इंस्टेंस बर्लिन समय में 9:00 AM होना चाहिए। जब बर्लिन DST स्विच करता है तो UTC वैल्यू बदल जाएगी, और वह सही है।
जब उपयोगकर्ता यात्रा करते हैं, तो व्यवहार के बारे में स्पष्ट रहें। एक Berlin‑anchored इवेंट अभी भी Berlin समय में 9:00 AM होगा, और न्यूयॉर्क में यात्रा कर रहे व्यक्ति को यह उनके स्थानीय समय में कन्वर्ट करके दिखाई देगा। अगर आप ऐसे "floating" इवेंट्स को सपोर्ट करते हैं जो दर्शक के वर्तमान टाइम ज़ोन का अनुसरण करते हैं, तो इसे स्पष्ट रूप से लेबल करें। यह उपयोगी है, पर जब इसे स्पष्ट न किया जाए तो यह लोगों को चौंका देता है।
DST समस्याएँ उपयोगकर्ताओं को यादृच्छिक लगती हैं क्योंकि ऐप बुक करते समय एक समय दिखाता है और बाद में अलग दिखाता है। समाधान सिर्फ तकनीकी नहीं है। आपको स्पष्ट नियम और स्पष्ट शब्द चाहिए।
जब घड़ियाँ आगे कूदती हैं, तो कुछ स्थानीय समय मौजूद ही नहीं होते। क्लासिक उदाहरण 02:30 है DST शुरू होने वाले दिन। अगर आप किसी को उसे चुनने दें, तो आपको तय करना होगा कि उसका मतलब क्या है।
जब घड़ियाँ पीछे जाती हैं, तो उल्टा होता है: वही स्थानीय समय दो बार होता है। "01:30" पहली occurrence (शिफ्ट से पहले) या दूसरी (शिफ्ट के बाद) हो सकती है। अगर आप पूछते नहीं हैं, तो आप अनुमान लगा रहे हैं, और लोग जब वे जुड़ते हैं तो एक घंटा पहले या बाद आकर नोटिस करेंगे।
प्रैक्टिकल नियम जो आश्चर्य रोकते हैं:
एक वास्तविक सपोर्ट टिकट की शुरुआत: किसी ने अगले महीने के लिए New York में "02:30" बुक किया, फिर जिस दिन आया ऐप चुपचाप "03:30" दिखाने लगा। बनाए जाने के समय बेहतर कॉपी सरल है: "Mar 10 को घड़ी बदलने के कारण यह समय मौजूद नहीं है। 01:30 या 03:00 चुनें।" अगर आप ऑटो‑एडजस्ट करते हैं, तो कहें: "हमने इसे 03:00 पर मूव कर दिया क्योंकि 02:30 उस दिन स्किप हो जाता है।"
अगर आप DST को UI का एक किनारा मानते हैं, तो यह भरोसे का सवाल बनकर उभरता है। अगर आप इसे एक प्रोडक्ट नियम मानते हैं, तो यह पूर्वानुमानित बन जाता है।
अधिकांश गुस्से भरे टिकट कुछ बार-बार होने वाली गलतियों से आते हैं। ऐप ऐसा लगता है कि "समय बदल गया", पर असली समस्या यह है कि नियम डेटा, कोड, और कॉपी में स्पष्ट रूप से नहीं बनाए गए थे।
एक सामान्य विफलता केवल ऑफ़सेट (-05:00) स्टोर करना है बजाय असली IANA टाइम ज़ोन (America/New_York) के। ऑफ़सेट DST शुरू या समाप्त होने पर बदलते हैं, इसलिए मार्च में सही दिखने वाला इवेंट नवंबर में गलत हो सकता है।
टाइम ज़ोन संक्षेप भी एक अक्सर की हुई गड़बड़ी है। "EST" अलग लोगों और सिस्टम्स के लिए अलग मतलब रख सकता है, और कुछ प्लेटफ़ॉर्म संक्षेपों को असंगत रूप से मैप करते हैं। एक पूरा टाइम ज़ोन ID स्टोर करें और संक्षेप को केवल डिस्प्ले‑ओनली टेक्स्ट मानें, अगर आप उन्हें दिखाते भी हैं।
All-day इवेंट्स अपनी श्रेणी हैं। अगर आप all-day को "midnight UTC" के रूप में स्टोर करते हैं, तो नकारात्मक ऑफ़सेट वाले उपयोगकर्ता अक्सर इसे एक दिन पहले देखेंगे। All-day को तिथियों और उन तिथियों की व्याख्या करने वाले जोन के साथ स्टोर करें।
कोड रिव्यू के लिए एक छोटा चेकलिस्ट:
00:00 UTC) के रूप में स्टोर न करें।रिमाइंडर और इनवाइट्स तब भी गलत हो सकती हैं जब इवेंट स्टोरेज सही हो। उदाहरण: किसी ने "9:00 AM Berlin time" बनाया और 8:45 AM Berlin समय पर रिमाइंडर चाहता है। अगर आपका जॉब शेड्यूलर UTC में चलता है और आप गलती से "8:45" को लोकल सर्वर समय मान लेते हैं, तो रिमाइंडर जल्दी या देर से फायर होंगे।
क्रॉस‑प्लैटफ़ॉर्म मतभेद इसे और बिगाड़ते हैं। एक क्लाइंट अस्पष्ट समय को डिवाइस ज़ोन से व्याख्यायित कर सकता है, दूसरा इवेंट जोन का उपयोग कर सकता है, और तीसरा कैश्ड DST नियम लागू कर सकता है। अगर आप लगातार व्यवहार चाहते हैं, तो कन्वर्शन और रिकरेंस एक्सपेंशन को एक जगह (आम तौर पर सर्वर) में रखें ताकि हर क्लाइंट एक ही परिणाम देखे।
एक सरल संज्ञानात्मक परीक्षण: उस सप्ताह में एक इवेंट बनाएं जब DST बदलता है, उसे दो डिवाइसों पर अलग‑अलग ज़ोन्स पर देखें, और पुष्टि करें कि स्टार्ट टाइम, तारीख और रिमाइंडर टाइम सभी उस नियम से मिलते हैं जो आपने उपयोगकर्ताओं को वादा किया था।
अधिकांश टाइम ज़ोन बग विकास के दौरान बग जैसे नहीं दिखते। वे तब दिखाई देते हैं जब कोई यात्रा करता है, जब DST पलटता है, या जब दो लोग स्क्रीनशॉट की तुलना करते हैं।
यकीन करें कि आपका डेटा मॉडल उस तरह के समय से मेल खाता है जिससे आप निपट रहे हैं। एक one-time इवेंट को एक वास्तविक क्षण की जरूरत होती है। एक रिकरिंग इवेंट को एक स्थान से जुड़ा नियम चाहिए।
America/New_York) स्टोर करें, सिर्फ ऑफ़सेट नहीं।2026-01-16T14:00Z) के बीच स्पष्ट अंतर रखें।DST दो खतरनाक क्षण पैदा करता है: वे समय जो मौजूद नहीं हैं (spring forward) और वे समय जो दोबारा घटित होते हैं (fall back)। आपकी ऐप को तय करना होगा कि क्या करना है, और इसे लगातार करना होगा।
परीक्षण परिदृश्य: बर्लिन में "सोमवार 09:00" सेट की गई साप्ताहिक टीम मीटिंग। मीटिंग टाइम किसी न्यूयॉर्क वाले के लिए DST से पहले और बाद दोनों समय देखें, और फिर US के DST बदलने के बाद भी देखें (वे अलग तारीख़ों पर स्विच करते हैं)।
कई गुस्से भरे टिकट UI से आते हैं जो टाइम ज़ोन छुपाते हैं। लोग वही मान लेते हैं जो वे चाहते हैं।
अपने लैपटॉप के टाइम ज़ोन और एक ही लोकेल फ़ॉर्मैट पर भरोसा मत करें।
लंदन‑आधारित फ़ाउंडर एक साप्ताहिक स्टैंडअप न्यूयॉर्क के एक टीममेट के साथ शेड्यूल करता है। वे "मंगलवार 10:00" चुनते हैं और मान लेते हैं कि यह हमेशा लंदन के लिए सुबह और न्यूयॉर्क के लिए जल्दी ही रहेगा।
सुरक्षित सेटअप यह है कि मीटिंग को "Europe/London में हर मंगलवार 10:00" माना जाए, हर occurrence को लंदन समय में कैलकुलेट करें, उस occurrence के लिए वास्तविक इंस्टैंट (UTC) स्टोर करें, और दर्शकों को उनका लोकल समय दिखाएँ।
वसंत के DST गैप के आसपास, यूएस घड़ियाँ यूके से पहले बदलता है:
आयोजक के लिए कुछ भी "हिला" नहीं। मीटिंग लंदन समय में 10:00 पर रही। जो बदलता है वह केवल न्यूयॉर्क का ऑफ़सेट कुछ हफ्तों के लिए था।
रिमाइंडर को हर व्यक्ति के लिए वही दिखने वाली चीज़ के अनुसार फॉलो करना चाहिए, न कि "वे पहले क्या देखते थे"। अगर न्यूयॉर्क टीममेट का 15‑मिनट रिमाइंडर है, तो वह US बदलाव से पहले 05:45 पर फायर करेगा, गैप सप्ताहों में 06:45 पर फायर करेगा, बिना किसी ने इवेंट एडिट किए।
अब एक एडिट जोड़ें: दो दर्दनाक सुबहों के बाद, लंदन आयोजक अगली हफ्ते से स्टैंडअप को 10:30 लंदन समय पर बदल देता है। एक अच्छा सिस्टम इरादे संरक्षित करता है: बदलाव आयोजक के टाइम ज़ोन में लागू किया जाता है, भविष्य के occurrences के लिए नए UTC इंस्टैंट जेनरेट होते हैं, और पिछले occurrences वैसे ही छोड़े जाते हैं जैसे वे थे।
अच्छी कॉपी सपोर्ट टिकट रोकती है: "हर मंगलवार 10:00 (London time) दोहराता है। आमंत्रित लोग इसे अपने लोकल समय में देखते हैं। टाइम्स डेलाइट सेविंग शुरू/खत्म होने पर 1 घंटे से शिफ्ट हो सकते हैं।"
अधिकांश "टाइम ज़ोन बग" उपयोगकर्ता अपेक्षा बग होते हैं। आपका डेटा मॉडल सही हो सकता है, पर अगर आपकी UI कॉपी अस्पष्ट है तो लोग मान लेते हैं कि ऐप उनका मन पढ़ लेगा। टाइम ज़ोन को एक UX वादा मानें, सिर्फ़ बैकएंड विवरण नहीं।
किसी भी जगह जहाँ समय मेन UI के बाहर दिखाई देता है खासकर नोटिफिकेशन्स और ईमेल में, वहां टाइम ज़ोन का नाम लिखकर शुरू करें। सिर्फ "10:00 AM" पर निर्भर न रहें। ज़ोन को उसके ठीक बगल में रखें और फ़ॉर्मैट को लगातार रखें।
कन्फ्यूजन कम करने वाले कॉपी पैटर्न:
DST दिनों के लिए भी दोस्ताना त्रुटि संदेश चाहिए। अगर उपयोगकर्ता ने ऐसा समय चुना जो मौजूद नहीं है (जैसे spring‑forward रात को 2:30 AM), तो तकनीकी शब्दावली से बचें और विकल्प दें: "Mar 10 को 2:30 AM उपलब्ध नहीं है क्योंकि घड़ियाँ आगे कूदती हैं। 1:30 AM या 3:30 AM चुनें।" अगर किसी समय का दोबार होना संभव है (fall‑back), तो सीधे पूछें: "क्या आप पहले 1:30 AM चाहते हैं या दूसरे?"
सुरक्षित बनाने के लिए पूरा फ़्लो (बनाना, आमंत्रित करना, किसी दूसरे जोन में देखना, DST के बाद एडिट करना) प्रोटोटाइप करें और तभी स्क्रीन पॉलिश करें:
अगर आप जल्दी से शेड्यूलिंग फीचर बना रहे हैं, तो चैट‑टू‑ऐप प्लेटफ़ॉर्म जैसे Koder.ai आपकी नियम, स्कीमा, और UI पर जल्दी इटरेट करने में मदद कर सकते हैं। गति अच्छी है, पर वही अनुशासन लागू होता है: इंस्टैंट UTC में स्टोर करें, इवेंट की मंशा के लिए IANA टाइम ज़ोन रखें, और हमेशा यूज़र्स को दिखाएँ कि वे किस टाइम ज़ोन को देख रहे हैं।