इस पेज का अनुवाद Cloud Translation API से किया गया है.

कैलेंडर और इवेंट

इस गाइड में कैलेंडर, इवेंट, और उनके बीच के संबंध के बारे में बताया गया है.

कैलेंडर

कैलेंडर, एक-दूसरे से जुड़े इवेंट का कलेक्शन होता है. इसमें अतिरिक्त मेटाडेटा भी शामिल होता है. जैसे, खास जानकारी, डिफ़ॉल्ट समय क्षेत्र, जगह वगैरह. हर कैलेंडर की पहचान एक आईडी से होती है, जो एक ईमेल पता होता है. कैलेंडर को अन्य लोगों के साथ शेयर किया जा सकता है. प्राइमरी कैलेंडर का मालिकाना हक, उससे जुड़े उपयोगकर्ता खाते के पास होता है. अन्य कैलेंडर का मालिकाना हक, डेटा के किसी एक मालिक के पास होता है.

इवेंट

इवेंट, किसी खास तारीख या समय सीमा से जुड़ा ऑब्जेक्ट होता है. इवेंट की पहचान एक यूनीक आईडी से की जाती है. इवेंट में शुरू और खत्म होने की तारीख और समय के अलावा, अन्य डेटा भी होता है. जैसे, खास जानकारी, ब्यौरा, जगह, स्टेटस, रिमाइंडर, अटैचमेंट वगैरह.

इवेंट के टाइप

Google Calendar में एक बार होने वाले और बार-बार होने वाले इवेंट बनाए जा सकते हैं:

सिंगल इवेंट, किसी खास इवेंट को दिखाता है.
बार-बार होने वाले इवेंट में, एक से ज़्यादा बार होने वाले इवेंट शामिल होते हैं.

इवेंट समय के हिसाब से या पूरे दिन के लिए भी हो सकते हैं:

समय के हिसाब से होने वाला इवेंट, समय के दो खास बिंदुओं के बीच होता है. तय समय पर होने वाले इवेंट के लिए, start.dateTime और end.dateTime फ़ील्ड का इस्तेमाल किया जाता है. इससे यह तय किया जाता है कि इवेंट कब होगा.
पूरे दिन चलने वाला इवेंट, पूरे दिन या लगातार कई दिनों तक चलता है. पूरे दिन चलने वाले इवेंट के लिए, start.date और end.date फ़ील्ड का इस्तेमाल किया जाता है. इससे यह तय किया जाता है कि इवेंट कब होगा. ध्यान दें कि पूरे दिन के इवेंट के लिए, टाइमज़ोन फ़ील्ड का कोई मतलब नहीं है.

इवेंट के शुरू और खत्म होने का समय या तो दोनों में होना चाहिए या दोनों पूरे दिन के इवेंट होने चाहिए. उदाहरण के लिए, start.date और end.dateTime

को एक साथ तय करना मान्य नहीं है.

आयोजक

इवेंट का सिर्फ़ एक आयोजक होता है. यह वह कैलेंडर होता है जिसमें इवेंट की मुख्य कॉपी मौजूद होती है. इवेंट में एक से ज़्यादा मेहमान भी शामिल हो सकते हैं. आम तौर पर, किसी इवेंट में शामिल होने वाला व्यक्ति, न्योता पाने वाले उपयोगकर्ता का मुख्य कैलेंडर होता है.

इस डायग्राम में, कैलेंडर, इवेंट, और उनसे जुड़े अन्य एलिमेंट के बीच के संबंध को दिखाया गया है:

प्राइमरी कैलेंडर और अन्य कैलेंडर

मुख्य कैलेंडर, एक खास तरह का कैलेंडर होता है. यह किसी एक उपयोगकर्ता खाते से जुड़ा होता है. यह कैलेंडर, हर नए उपयोगकर्ता खाते के लिए अपने-आप बन जाता है. इसका आईडी आम तौर पर उपयोगकर्ता के मुख्य ईमेल पते से मेल खाता है. जब तक खाता मौजूद है, तब तक इसका मुख्य कैलेंडर न तो मिटाया जा सकता है और न ही उपयोगकर्ता इसे "अन-ओन्ड" कर सकता है. हालांकि, इसे अब भी अन्य उपयोगकर्ताओं के साथ शेयर किया जा सकता है.

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

अहम जानकारी: कैलेंडर बनाते समय, हम सुझाव देते हैं कि आपका ऐप्लिकेशन, कैलेंडर के डेटा के मालिक के तौर पर पुष्टि करे. किसी ऐप्लिकेशन को किसी उपयोगकर्ता की ओर से कार्रवाई करने की अनुमति देने के लिए, पूरे डोमेन के लोगों को डेटा का ऐक्सेस दें सुविधा का इस्तेमाल किया जा सकता है. पुष्टि करने के लिए, सेवा खाते का इस्तेमाल न करें. अगर पुष्टि करने के लिए सेवा खाते का इस्तेमाल किया जाता है, तो सेवा खाता डेटा का मालिक होता है. इससे अनचाही समस्याएं हो सकती हैं. उदाहरण के लिए, अगर कोई सेवा खाता डेटा का मालिक है, तो डेटा का मालिकाना हक ट्रांसफ़र नहीं किया जा सकता.

कैलेंडर और कैलेंडर की सूची

Calendars कलेक्शन, सभी मौजूदा कैलेंडर दिखाता है. इसका इस्तेमाल कैलेंडर बनाने और मिटाने के लिए किया जा सकता है. इसके अलावा, कैलेंडर का ऐक्सेस रखने वाले सभी उपयोगकर्ताओं के साथ शेयर की गई ग्लोबल प्रॉपर्टी को वापस लाया जा सकता है या सेट किया जा सकता है. उदाहरण के लिए, किसी कैलेंडर का टाइटल और डिफ़ॉल्ट टाइम ज़ोन, ग्लोबल प्रॉपर्टी होती हैं.

CalendarList, कैलेंडर की उन सभी एंट्री का कलेक्शन होता है जिन्हें किसी उपयोगकर्ता ने अपनी सूची में जोड़ा है. यह सूची, वेब यूज़र इंटरफ़ेस के बाएं पैनल में दिखती है. इसका इस्तेमाल, उपयोगकर्ताओं की सूची में मौजूदा कैलेंडर जोड़ने और हटाने के लिए किया जा सकता है. इसका इस्तेमाल, उपयोगकर्ता के हिसाब से कैलेंडर की प्रॉपर्टी की वैल्यू को वापस पाने और सेट करने के लिए भी किया जाता है. जैसे, डिफ़ॉल्ट रिमाइंडर. एक और उदाहरण फ़ोरग्राउंड कलर है, क्योंकि अलग-अलग उपयोगकर्ताओं के पास एक ही कैलेंडर के लिए अलग-अलग रंग सेट करने का विकल्प होता है.

यहां दी गई टेबल में, दोनों कलेक्शन के लिए कार्रवाइयों के मतलब की तुलना की गई है:

कार्रवाई	कैलेंडर	CalendarList
`insert`	यह कुकी, नया सेकंडरी कैलेंडर बनाती है. यह कैलेंडर, क्रिएटर की कैलेंडर सूची में भी जुड़ जाता है. इसे तब तक नहीं हटाया जा सकता, जब तक कैलेंडर को मिटा न दिया जाए या ट्रांसफ़र न कर दिया जाए.	इससे उपयोगकर्ता की सूची में मौजूदा कैलेंडर डाला जाता है.
`delete`	इस तरीके का इस्तेमाल करके, सेकंडरी कैलेंडर मिटाया जा सकता है.	इससे उपयोगकर्ता की सूची से कैलेंडर हट जाता है.
`get`	यह कुकी, कैलेंडर का मेटाडेटा वापस लाती है. जैसे, टाइटल, टाइम ज़ोन.	यह कुकी, मेटाडेटा के साथ-साथ उपयोगकर्ता के हिसाब से बनाई गई सेटिंग को भी वापस लाती है. जैसे, रंग या सूचनाओं को खारिज करने की सुविधा.
`patch`/`update`	इस अनुमति की मदद से, कैलेंडर के मेटाडेटा में बदलाव किया जाता है.	यह उपयोगकर्ता के हिसाब से कैलेंडर की प्रॉपर्टी में बदलाव करता है.

बार-बार होने वाले इवेंट

कुछ इवेंट नियमित तौर पर कई बार होते हैं. जैसे, हर हफ़्ते होने वाली मीटिंग, जन्मदिन, और छुट्टियां. शुरू और खत्म होने के समय के अलावा, दोहराए जाने वाले ये इवेंट अक्सर एक जैसे होते हैं.

अगर कोई इवेंट तय किए गए शेड्यूल के हिसाब से बार-बार होता है, तो उसे बार-बार होने वाला इवेंट कहा जाता है. सिंगल इवेंट, बार-बार नहीं होते और सिर्फ़ एक बार होते हैं.

बार-बार होने का नियम

बार-बार होने वाले इवेंट का शेड्यूल दो हिस्सों में तय किया जाता है:

इसके शुरू और खत्म होने के फ़ील्ड (जो पहली बार होने वाले इवेंट को इस तरह से तय करते हैं जैसे कि यह सिर्फ़ एक स्टैंड-अलोन सिंगल इवेंट हो) और
दोहराए जाने की जानकारी देने वाला फ़ील्ड (इससे यह तय होता है कि इवेंट को समय-समय पर कैसे दोहराया जाना चाहिए).

recurrence फ़ील्ड में स्ट्रिंग की एक ऐसी कैटगरी होती है जो RFC 5545 में तय की गई एक या कई RRULE, RDATE या EXDATE प्रॉपर्टी को दिखाती है.

RRULE प्रॉपर्टी सबसे अहम होती है, क्योंकि यह इवेंट को दोहराने के लिए सामान्य नियम तय करती है. इसमें कई कॉम्पोनेंट शामिल होते हैं. इनमें से कुछ ये हैं:

FREQ — इससे यह तय होता है कि इवेंट को कितनी बार दोहराया जाना चाहिए. जैसे, DAILY या WEEKLY. यह पैरामीटर ज़रूरी है.
INTERVAL — यह FREQ के साथ मिलकर काम करता है. इससे यह तय किया जाता है कि इवेंट को कितनी बार दोहराया जाना चाहिए. उदाहरण के लिए, FREQ=DAILY;INTERVAL=2 का मतलब है कि हर दो दिन में एक बार.
COUNT — यह इवेंट कितनी बार दोहराया जाना चाहिए.

इवेंट के बार-बार होने की सुविधा को बंद करने के लिए, COUNT या UNTIL में से किसी एक का इस्तेमाल किया जा सकता है. एक ही नियम में दोनों का इस्तेमाल न करें.
UNTIL — वह तारीख या तारीख और समय जब तक इवेंट को दोहराया जाना चाहिए. इसमें वह तारीख भी शामिल है.
BYDAY — हफ़्ते के वे दिन जिन पर इवेंट को दोहराया जाना चाहिए (SU, MO, TU वगैरह). इसी तरह के अन्य कॉम्पोनेंट में BYMONTH, BYYEARDAY, और BYHOUR शामिल हैं.

RDATE प्रॉपर्टी से, इवेंट के होने की अतिरिक्त तारीखों या तारीख-समय के बारे में पता चलता है. उदाहरण के लिए, RDATE;VALUE=DATE:19970101,19970120. इसका इस्तेमाल, RRULE में शामिल नहीं किए गए अन्य इवेंट जोड़ने के लिए करें.

EXDATE प्रॉपर्टी, RDATE प्रॉपर्टी की तरह ही होती है. हालांकि, यह उन तारीखों या तारीख-समय के बारे में बताती है जब इवेंट नहीं होना चाहिए. इसका मतलब है कि उन इवेंट को शामिल नहीं किया जाना चाहिए. यह, बार-बार होने वाली घटना के नियम से जनरेट किए गए मान्य इंस्टेंस की ओर ले जाना चाहिए.

EXDATE और RDATE में टाइम ज़ोन हो सकता है. साथ ही, पूरे दिन चलने वाले इवेंट के लिए, ये तारीखें होनी चाहिए (तारीख और समय नहीं).

हर प्रॉपर्टी, recurrence फ़ील्ड में कई बार दिख सकती है. बार-बार होने की स्थिति को, सभी RRULE और RDATE नियमों के यूनीयन के तौर पर तय किया जाता है. इसमें से उन नियमों को घटा दिया जाता है जिन्हें सभी EXDATE नियमों के तहत शामिल नहीं किया गया है.

बार-बार होने वाले इवेंट के कुछ उदाहरण यहां दिए गए हैं:

ऐसा इवेंट जो हर मंगलवार और शुक्रवार को सुबह 6 बजे से 7 बजे तक होता है. यह 15 सितंबर, 2015 से शुरू हुआ था और 29 सितंबर को पांच बार होने के बाद बंद हो गया:
```
...
"start": {
 "dateTime": "2015-09-15T06:00:00+02:00",
 "timeZone": "Europe/Zurich"
},
"end": {
 "dateTime": "2015-09-15T07:00:00+02:00",
 "timeZone": "Europe/Zurich"
},
"recurrence": [
 "RRULE:FREQ=WEEKLY;COUNT=5;BYDAY=TU,FR"
],
…
```
पूरे दिन चलने वाला इवेंट, जो 1 जून, 2015 को शुरू होता है और पूरे महीने हर तीन दिन में दोहराया जाता है. इसमें 10 जून को छोड़कर 9 और 11 जून शामिल हैं:
```
...
"start": {
 "date": "2015-06-01"
},
"end": {
 "date": "2015-06-02"
},
"recurrence": [
 "EXDATE;VALUE=DATE:20150610",
 "RDATE;VALUE=DATE:20150609,20150611",
 "RRULE:FREQ=DAILY;UNTIL=20150628;INTERVAL=3"
],
…
```

उदाहरण और अपवाद

बार-बार होने वाले इवेंट में कई उदाहरण शामिल होते हैं: अलग-अलग समय पर होने वाले इवेंट. ये इंस्टेंस, इवेंट के तौर पर काम करते हैं.

बार-बार होने वाले इवेंट में किए गए बदलाव, पूरे इवेंट और उसके सभी इंस्टेंस पर लागू हो सकते हैं. इसके अलावा, ये बदलाव सिर्फ़ अलग-अलग इंस्टेंस पर भी लागू हो सकते हैं. ऐसे इंस्टेंस जो बार-बार होने वाले पैरंट इवेंट से अलग होते हैं उन्हें अपवाद कहा जाता है.

उदाहरण के लिए, किसी अपवाद की खास जानकारी, शुरू होने का समय अलग हो सकता है या उसमें सिर्फ़ उस अपवाद के लिए न्योता पाए हुए अतिरिक्त लोग शामिल हो सकते हैं. बार-बार दोहराए जाने वाले इवेंट को हटाए बिना, किसी इवेंट को पूरी तरह से रद्द किया जा सकता है. इवेंट status में, इवेंट रद्द होने की जानकारी दिखती है.

Google Calendar API के ज़रिए, बार-बार होने वाले इवेंट और इंस्टेंस के साथ काम करने के उदाहरण यहां देखे जा सकते हैं.

समय क्षेत्र

टाइम ज़ोन, किसी ऐसे क्षेत्र को दिखाता है जहां एक ही स्टैंडर्ड टाइम का इस्तेमाल किया जाता है. Google Calendar API में, IANA टाइम ज़ोन आइडेंटिफ़ायर का इस्तेमाल करके टाइम ज़ोन तय किए जाते हैं.

आपके पास दोनों कैलेंडर और इवेंट के लिए टाइम ज़ोन सेट करने का विकल्प होता है. यहां दिए गए सेक्शन में, इन सेटिंग के असर के बारे में बताया गया है.

कैलेंडर का टाइम ज़ोन

कैलेंडर के टाइम ज़ोन को डिफ़ॉल्ट टाइम ज़ोन भी कहा जाता है, क्योंकि यह क्वेरी के नतीजों पर असर डालता है. कैलेंडर के टाइम ज़ोन से, events.get(), events.list(), और events.instances() तरीकों से समय की वैल्यू को समझने या दिखाने के तरीके पर असर पड़ता है.

क्वेरी के नतीजे के टाइम-ज़ोन को बदलना: get(), list(), और instances() तरीकों के नतीजे, उस टाइम ज़ोन में दिखाए जाते हैं जिसे आपने timeZone पैरामीटर में सेट किया है. इस पैरामीटर को शामिल न करने पर, ये सभी तरीके डिफ़ॉल्ट रूप से कैलेंडर के टाइम ज़ोन का इस्तेमाल करते हैं.
पूरे दिन चलने वाले इवेंट को समयसीमा वाली क्वेरी से मैच करना: list() और instances() तरीकों की मदद से, शुरू और खत्म होने के समय के फ़िल्टर तय किए जा सकते हैं. साथ ही, यह तरीका उन इंस्टेंस को दिखाता है जो तय की गई सीमा में आते हैं. कैलेंडर के टाइम ज़ोन का इस्तेमाल, पूरे दिन चलने वाले इवेंट के शुरू और खत्म होने के समय का हिसाब लगाने के लिए किया जाता है. इससे यह तय किया जाता है कि इवेंट, फ़िल्टर की खास जानकारी के मुताबिक है या नहीं.

इवेंट समय क्षेत्र

इवेंट के इंस्टेंस के शुरू और खत्म होने का समय होता है. इन समयों के बारे में जानकारी देते समय, टाइम ज़ोन की जानकारी भी शामिल की जा सकती है. टाइम ज़ोन की जानकारी कई तरीकों से दी जा सकती है. यहां दिए गए सभी उदाहरणों में एक ही समय बताया गया है:

dateTime फ़ील्ड में टाइम ज़ोन का ऑफ़सेट शामिल करें. उदाहरण के लिए, 2017-01-25T09:00:00-0500.
बिना ऑफ़सेट के समय की जानकारी दें. उदाहरण के लिए, 2017-01-25T09:00:00. साथ ही, timeZone फ़ील्ड को खाली छोड़ दें. इससे डिफ़ॉल्ट टाइम ज़ोन का इस्तेमाल किया जाएगा.
ऑफ़सेट के बिना समय की जानकारी दें. उदाहरण के लिए, 2017-01-25T09:00:00. हालांकि, टाइम ज़ोन की जानकारी देने के लिए timeZone फ़ील्ड का इस्तेमाल करें.

अगर आपको इवेंट के समय यूटीसी में बताने हैं, तो ऐसा भी किया जा सकता है:

यूटीसी में समय बताएं: 2017-01-25T14:00:00Z या शून्य ऑफ़सेट 2017-01-25T14:00:00+0000 का इस्तेमाल करें.

इन सभी मामलों में, इवेंट के समय का इंटरनल रिप्रेजेंटेशन एक जैसा होता है. हालांकि, timeZone फ़ील्ड सेट करने पर, इवेंट में टाइम ज़ोन जुड़ जाता है. ठीक वैसे ही जैसे Calendar के यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, इवेंट का टाइम ज़ोन सेट करने पर होता है:

बार-बार होने वाले इवेंट का टाइम ज़ोन

बार-बार होने वाले इवेंट के लिए, एक ही टाइमज़ोन की जानकारी देनी चाहिए. इसकी ज़रूरत इवेंट की बार-बार होने की जानकारी को बढ़ाने के लिए होती है.