ICS को CSV में बदलें

कैलेंडर ऐप आगे देखने के लिए बना है, पीछे मुड़कर जोड़ने में कमज़ोर है। पिछली तिमाही किसी एक क्लाइंट को कितने घंटे गए। कौन-सी दोहराने वाली मीटिंग चुपचाप चौदह लोगों तक बढ़ गई। कोई भी शेड्यूल करने से पहले हफ़्ते का कितना हिस्सा पहले से भरा है। इनमें से कोई भी कैलेंडर का व्यू नहीं है, और यह सब एक पिवट टेबल है।

इसीलिए एक्सपोर्ट गिनने के लिए है। यह सोच तय करती है कि इस बदलाव की कौन-सी सीमा गंभीर है — किसी इवेंट का रंग खोना कुछ नहीं, और इवेंट के दोहराए जाने का सच खोना सब कुछ। अगले दो हिस्से इसी बारे में हैं।

किसी भी योग पर भरोसा करने से पहले यह पढ़ना ज़रूरी है। कैलेंडर फ़ॉर्मेट में दोहराने वाली श्रृंखला एक इवेंट के तौर पर रखी जाती है जिसके साथ एक recurrence rule होता है — पिछले साल भर का रोज़ का stand-up एक `VEVENT` है जिसमें `RRULE` लिखा है साप्ताहिक, कार्यदिवसों पर, एक तारीख़ तक।

यहाँ बनने वाले कॉलम इवेंट के अपने गुण हैं: summary, start, end, location, description, organiser, status, पहचान संख्या और attendees। `RRULE`, `RDATE` और `EXDATE` इनमें नहीं, तो पूरी श्रृंखला ठीक एक पंक्ति देती है, पहली बार के समय के साथ। एक तिमाही के stand-up एक तीस-मिनट की पंक्ति बनते हैं। ड्यूरेशन कॉलम जोड़ने वाली कोई भी चीज़ उतनी ग़लत निकलेगी जितना दोहराने वाले इवेंट ने असल में समय लिया, और ज़्यादातर काम के कैलेंडर में यह समय का ज़्यादातर हिस्सा होता है।

हल आगे नहीं, पीछे है, और यह लगने से आसान है। Google Calendar और Outlook दोनों, जब पूरे कैलेंडर की बजाय एक तारीख़ सीमा एक्सपोर्ट या प्रिंट करने को कहा जाए, नियम की बजाय अलग-अलग बार दिखाते हैं — तो "इस तिमाही" एक्सपोर्ट करने पर हर stand-up अपना अलग `VEVENT` बनता है और हर एक एक पंक्ति।

जहाँ यह उपलब्ध न हो, फैलाना एक स्क्रिप्ट का काम है, स्प्रेडशीट का नहीं। दो तारीख़ों के बीच का काम Python का `icalendar` `dateutil.rrule` के साथ, या Node का `ical-expander` पैकेज कर सकता है। दोनों ही सूरत में फ़ाइल के अभी ICS रहते हुए यह कीजिए। एक बार टेबल बन गई तो नियम गायब हो चुका है और कुछ भी उसे दोबारा नहीं बना सकता, क्योंकि टेबल ने कभी उसे ढोया ही नहीं।

क्रम में: `summary`, `start`, `end`, `location`, `description`, `organizer`, `status`, `uid`, `attendees`। हर इवेंट सभी नौ के साथ पंक्ति बनाता है, जहाँ वह गुण न हो वहाँ ख़ाली, इसलिए टेबल हमेशा आयताकार रहती है चाहे स्रोत कितना भी असमान हो।

दो पर ध्यान देने लायक़ है। `status` पुष्ट, अस्थायी और रद्द इवेंट के बीच फ़र्क़ करता है, और रद्द इवेंट भी पंक्ति बनाते हैं — गिनने से पहले उन्हें फ़िल्टर कीजिए, वरना रद्द हुई पूरे दिन की वर्कशॉप बिताया समय समझकर गिन ली जाएगी। और `uid` कैलेंडर की दी हुई स्थिर पहचान है, जो दो एक्सपोर्ट के मिलने पर डुप्लीकेट हटाने का इकलौता भरोसेमंद तरीक़ा है।

टाइमस्टैम्प कैलेंडर के छोटे रूप से ISO 8601 में फिर से लिखे जाते हैं, तो `20260301T080000Z` बनता है `2026-03-01T08:00:00Z`, जिसे हर स्प्रेडशीट पहचानती है। जो नहीं किया जाता वह है ज़ोन के बीच बदलाव।

UTC में लिखा मान अपना Z रखता है। `TZID` पैरामीटर वाला मान उस ज़ोन के हिसाब से स्थानीय है, और वह बिना Z और बिना ऑफ़सेट के वैसे ही लिखा जाता है — इसे बदलने के लिए टाइम-ज़ोन डेटाबेस चाहिए, और UTC मान लेना हर अपॉइंटमेंट को घंटे भर खिसका देगा। नतीजा एक कॉलम है जिसमें कुछ सेल अपना ज़ोन बताते हैं और कुछ नहीं, और टेबल यह नहीं बताती बाक़ी किस ज़ोन में थे।

पूरे दिन का इवेंट टाइमस्टैम्प की बजाय date मान से लिखा जाता है, और यह start तथा end कॉलम में बिना समय हिस्से के सादा `2026-03-01` बनकर बदलता है। यह साफ़ है और सही क्रम में सॉर्ट होता है।

पेच फ़ॉर्मेट में है, बदलाव में नहीं: date मान के लिए end हमेशा exclusive होता है। 3 तारीख़ का एक-दिन का इवेंट शुरू 3 पर और ख़त्म 4 पर लिखा जाता है। किसी को तारीख़ सीमा बताने से पहले एक दिन घटा लीजिए, और ड्यूरेशन निकालने वाले किसी भी फ़ॉर्मूले में सावधान रहिए — यह हिसाब फ़ॉर्मेट के लिए सही है, उस वाक्य के लिए नहीं जो कोई इससे बनाएगा।

कैलेंडर फ़ॉर्मेट किसी इवेंट को end की बजाय start और duration बताने की इजाज़त देता है, और कुछ बनाने वाले सिस्टम हर चीज़ के लिए यही रूप इस्तेमाल करते हैं। सिर्फ़ end गुण किसी कॉलम में जाता है, तो ऐसे इवेंट भरे start और ख़ाली end के साथ आते हैं।

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

किसी आमंत्रण में attendee एक पते के तौर पर सहेजा जाता है और एक display name पैरामीटर में। पढ़ने लायक़ आधा हिस्सा रखा जाता है, तो सेल में "अन्ना वेबर" आता है जहाँ आमंत्रण में सामान्य नाम था, और `[email protected]` जहाँ नहीं था। कई attendee एक सेल में सेमीकोलन से जुड़ जाते हैं।

यह जान-बूझकर किया गया चुनाव है, `attendee1` से `attendee9` बनाने की बजाय, जो दसवें को काट देता और बाक़ी सबके लिए नौ ज़्यादातर-ख़ाली कॉलम छोड़ देता। Attendee गिनना अब सेल पर एक फ़ॉर्मूला है, कॉलम गिनने की बजाय।

कैलेंडर फ़ॉर्मेट में अपॉइंटमेंट से ज़्यादा कुछ होता है। टास्क `VTODO` हैं, जर्नल एंट्री `VJOURNAL`, फ़्री-बिज़ी ब्लॉक `VFREEBUSY`, और अलार्म इवेंट के भीतर `VALARM` बैठते हैं। यहाँ सिर्फ़ `VEVENT` पढ़ा जाता है।

जिस फ़ाइल में सिर्फ़ टास्क हों वह "इस फ़ाइल में कोई कैलेंडर प्रविष्टि नहीं मिली" पर रुक जाती है, जो सही है, नाकामी नहीं — रिमाइंडर ऐप का एक्सपोर्ट इवेंट का कैलेंडर नहीं है भले उसका एक्सटेंशन वही हो। जो इवेंट पढ़े जाते हैं उनसे भी अलार्म, अटैचमेंट और हर-attendee की जवाब स्थिति छोड़ दी जाती है, उसी वजह से जिस वजह से recurrence छूटता है — टेबल के पास इनके लिए कोई आकार नहीं।

खोलिए मत, इम्पोर्ट कीजिए। Excel में, Data फिर From Text/CSV, और start तथा end कॉलम को इम्पोर्ट करते समय Text तय कीजिए, वरना Excel इन्हें अपने हिसाब से दोबारा पढ़ेगा — ऑफ़सेट हटा देगा, मशीन की भाषा-सेटिंग के हिसाब से दोबारा फ़ॉर्मेट कर देगा, और एक ISO स्ट्रिंग को कुछ ऐसा बना देगा जो अब टेक्स्ट की तरह सॉर्ट नहीं होता।

Description भी ध्यान देने लायक़ है। मीटिंग विवरण में अक्सर कॉमा, उद्धरण चिह्न और असली लाइन-ब्रेक होते हैं — कोई चिपकाया गया एजेंडा, कोई डायल-इन ब्लॉक — और तीनों को उद्धरण चिह्न में लपेटकर संभाला जाता है, जो RFC 4180 का तरीक़ा है जिसे हर सही इम्पोर्टर पढ़ता है। शेल पाइपलाइन में सादा कॉमा पर बाँटना यह नहीं करेगा, इसलिए असली CSV रीडर इस्तेमाल कीजिए या TSV में बदल लीजिए।