Whenever – Python के लिए type-safe और DST-safe तारीख व समय प्रोसेसिंग तकनीक

• Whenever Python के datetime को बेहतर बनाकर DST सुरक्षा और type safety प्रदान करने वाली लाइब्रेरी है
• यह Rust और शुद्ध Python में उपलब्ध है, और performance बेहतरीन है
• Python standard library, Arrow, और Pendulum की तुलना में DST हैंडलिंग और type safety में बेहतर है
• nanosecond precision और नवीनतम GIL सुधारों का समर्थन करता है, और Rust extension के जरिए performance बढ़ाता है
• MIT license के तहत उपलब्ध है, और feedback के आधार पर लगातार बेहतर बनाया जा रहा है

---

Whenever परिचय

• Whenever Python के datetime मॉड्यूल की सीमाओं को दूर करने के लिए विकसित की गई लाइब्रेरी है
• यह DST सुरक्षा और type safety प्रदान करके कोड की शुद्धता बढ़ाती है
• इसे Rust और शुद्ध Python में implement किया गया है, और इसकी performance बेहतरीन है

standard library की सीमाएँ

• Python का datetime हमेशा DST को ध्यान में नहीं रखता
• type system में naive और aware datetime के बीच अंतर नहीं किया जा सकता

अन्य लाइब्रेरियों से तुलना

• Arrow user-friendly API देता है, लेकिन मूल समस्याओं को हल नहीं कर पाता
• Pendulum ने कुछ DST समस्याएँ हल कीं, लेकिन performance कम हो गई और maintenance भी कमज़ोर रहा

Whenever के फायदे

• DST-safe arithmetic और type-safe API प्रदान करता है
• performance बहुत अच्छी है, और Rust extension से यह और बेहतर होती है
• nanosecond precision और नवीनतम GIL सुधारों का समर्थन करता है

त्वरित शुरुआत

• Instant, ZonedDateTime, LocalDateTime जैसे explicit types प्रदान करता है
• DST-safe arithmetic और explicit conversion संभव हैं
• ISO8601, RFC3339, RFC2822 फ़ॉर्मैट की formatting और parsing का समर्थन करता है

रोडमैप

• 0.x संस्करण: feature parity हासिल करना और API सुधारना
• 1.0 संस्करण: API स्थिरता और backward compatibility सुनिश्चित करना

सीमाएँ

• ईस्वी 1 से 9999 तक के Gregorian calendar का समर्थन
• IANA TZ DB के अनुरूप time zone offset का समर्थन
• leap second का समर्थन नहीं करता

वर्ज़निंग और compatibility नीति

• Whenever semantic versioning का पालन करता है
• 1.0 संस्करण से पहले API बदलने की संभावना है

लाइसेंस

• MIT license के तहत उपलब्ध है, और Rust dependencies समान प्रकार के permissive licenses का उपयोग करती हैं

आभार

• Temporal, Noda Time, Joda Time प्रोजेक्ट्स से प्रेरित है
• Ruff project के benchmark comparison graph पर आधारित है

[GN⁺]

Hacker News टिप्पणियाँ

• अगर आपने अभी तक वह ब्लॉग पोस्ट नहीं पढ़ी है जो बताती है कि यह लाइब्रेरी क्यों मौजूद है, तो उसे पढ़ने की सिफारिश है। उसका शीर्षक है "Ten Python datetime pitfalls, and what libraries are (not) doing about it"
• यह लाइब्रेरी standard library में मौजूद Liskov violation की समस्या को ठीक करती है। standard library में dates की तुलना की जा सकती है, लेकिन datetime और date की तुलना करने पर error आता है। हाल ही में काम पर मुझे इसी समस्या से परेशानी हुई थी
• मैंने Arrow, Delorean, Pendulum और standard library datetime इस्तेमाल किए हैं, लेकिन आखिरकार Whenever चुना। यह वास्तव में datetime को संभालने के लिए ज्यादा उपयुक्त लगता है और ज्यादा सक्रिय रूप से maintained भी दिखता है। बाकी लाइब्रेरियों के बारे में हमेशा लगा कि वे edge cases छोड़ देती हैं। Pendulum का API में एक ज्यादा गहरा असर दिखता है
• क्या standard library का उपयोग करके, docs और changelog को ध्यान से पढ़कर, और जो ज़रूरी हो उसे खुद implement करने वाला मैं अकेला हूँ? मैंने कठिन तरीके से सीखा है कि dependencies प्रोजेक्ट को खराब कर सकती हैं। इसका मतलब यह नहीं कि यह लाइब्रेरी अच्छी नहीं है। बेशक इसके उपयोग के मामले हैं
• यह Rust या pure Python में उपलब्ध है। binary package इस्तेमाल करने या build करने की जटिलता performance लाभ की तुलना में शायद उचित नहीं है। pure Python version के लिए source से build करना और special flags देना पड़ता है, इसलिए उसे requirements.txt में निर्दिष्ट नहीं किया जा सकता
• अगर performance सबसे बड़ी प्राथमिकता नहीं है, तो pure Python version भी इस्तेमाल किया जा सकता है। मैं pure Python implementation के benchmarks भी देखना चाहता था। अगर यह Arrow से धीमा निकले तो?
• यह दिलचस्प है कि Pandas में datetime comparison नहीं जोड़ा गया है। शायद इसका उपयोग दूसरी लाइब्रेरियों की तुलना में कहीं ज्यादा dates को संभालने में होगा
• क्या किसी को पता है कि performance समस्याएँ वास्तव में कब मायने रखती हैं? मैं datetime को short-lived object के रूप में समझता हूँ। आप शायद अपने codebase में हजारों datetime objects नहीं रखना चाहेंगे। लगभग हर मामले में UTC काफी है। जब range के आधार on filter/bucket/aggregate करना होता है, तो datetime को tz के साथ filter/bucket/aggregate के मानदंड सेट करने के लिए इस्तेमाल किया जाता है, फिर उसे UTC में बदलकर आगे सिर्फ int comparisons की जाती हैं। Whenever जिन ज्यादातर मामलों को संभालता है, वे शायद तब होते हैं जब datetime long-lived object हो। मुझे ऐसी ज़रूरत बिल्कुल महसूस नहीं होती। मैं इसे client से tz input लेने के लिए इस्तेमाल करता हूँ और आते ही उसे UTC में बदल देता हूँ। अगर सच में tz की ज़रूरत हो, तो उसे अलग से store करता हूँ। ऐसा कम ही होता है (जैसे calendar में tz store करना पड़ता है, लेकिन शायद हर UTC value के साथ नहीं, बल्कि user level पर store करना चाहिए। दूसरा उदाहरण workforce scheduling है, जहाँ 8am-4pm या 8pm-4am location के अनुसार अलग मतलब रख सकते हैं। यह अब datetime नहीं बल्कि time zone में समय है)
• जब मुझे बुनियादी चीज़ों से आगे कुछ चाहिए होता है, तो मैं Arrow का उपयोग करता हूँ। यह लाइब्रेरी काफी दिलचस्प है। सिर्फ इसलिए नहीं कि इसमें edge cases की coverage ज्यादा है, बल्कि इसलिए भी कि इसमें Rustified mode और pure Python mode दोनों मिलते हैं। Whenever के साथ आपको किसी और बात की चिंता नहीं करनी पड़ती, और प्रोजेक्ट में बेहतर datetime handling चाहिए तो datetime पर वापस लौटने की ज़रूरत नहीं होती। इसे ऐसे environment में भी इस्तेमाल किया जा सकता है जहाँ Rust toolchain न हो या उसमें दिक्कत हो। Kudos
• लगता है कि पूरे industry/भाषा स्तर पर एक test suite बननी चाहिए। ऐसी जो बहुत सी date/time/calendar लाइब्रेरियों को test कर सके। browser acid tests जैसी, लेकिन सिर्फ बुनियादी कार्यक्षमता पर केंद्रित। मुझे यह नई लाइब्रेरी पसंद आई (धन्यवाद), लेकिन इसका नाम वास्तविक अर्थ के उलट संकेत देता है। "Whenever" ऐसा लगता है जैसे आपको परवाह नहीं, जबकि असल में आप इसे तभी इस्तेमाल करेंगे जब आपको परवाह हो। और Shakira भी, हाहा। Hmm, pedantic तो पहले से लिया जा चुका है। Timely, precise, punctual, meticulous, ahorita, pronto वगैरह। मुझे समय से जुड़े नाम पसंद हैं। आखिर में, इन links में से कोई भी immutability का ज़िक्र नहीं करता, जबकि उसे सबसे ऊपर बताया जाना चाहिए