`datetime.utcnow()` अब अप्रचलित है
`datetime.utcnow()` को deprecate करने के Python के फ़ैसले ने time, time zones, और “naive” बनाम “aware” datetimes को programming languages में कैसे दर्शाया जाए, इस पर लंबे समय से चली आ रही बहस को फिर से भड़का दिया है। टिप्पणीकार इस पर बहस करते हैं कि क्या सभी timestamps के साथ हमेशा स्पष्ट UTC या zone information होनी चाहिए, local बनाम global events (जैसे store hours या calendar appointments) को कैसे model किया जाए, और क्या यह बदलाव बड़े codebases, खासकर finance में, backward-compatibility और migration pain के लायक है। कई लोग मानते हैं कि Python का datetime API वर्षों से error-prone रहा है, लेकिन वे इस बात पर तीखे रूप से विभाजित हैं कि deprecation और eventual removal एक ज़रूरी सुधार है या अनावश्यक breaking change।
Naive बनाम timezone‑aware datetimes
- कई लोग सहमत हैं कि Python का “naive” बनाम “aware” विभाजन त्रुटिप्रवण है, खासकर जब दोनों को चुपचाप मिलाया जाता है।
- मुख्य शिकायत:
utcnow()सुनने में ऐसा लगता है कि यह एक UTC‑aware datetime लौटाएगा, लेकिन वास्तव में यह naive local‑semantics डेटा लौटाता है; इससे सूक्ष्म बग हुए हैं। - कुछ लोग तर्क देते हैं कि अवधारणात्मक रूप से “सभी वास्तविक datetimes के पास एक timezone होता है” और naive datetimes दुर्लभ होने चाहिए या स्पष्ट रूप से अलग प्रकार होने चाहिए।
- अन्य लोग ज़ोर देते हैं कि naive UTC एक वैध, कुशल आंतरिक परंपरा है, जिसका व्यापक उपयोग होता है (जैसे finance में), और इसे deprecate करना विघटनकारी है।
जहाँ local / naive times की ज़रूरत होती है
- आवर्ती या local events: “8am local” पर alarms, “10am in Europe/London” पर future appointments, store opening hours “9:30am local”, recurring meetings, stock-exchange open times.
- ये एक single UTC instant में साफ़ तौर पर नहीं बदलते, खासकर जब governments scheduling के बाद DST rules या offsets बदल देती हैं।
- कुछ लोग अलग types चाहते हैं: timestamps/instants बनाम local date/time बनाम recurring rules, ताकि misuse रोका जा सके।
Time को store और exchange करना
- “past events को UTC में store करो, display पर convert करो” के लिए मज़बूत समर्थन है; future events के मामले में असहमति है।
- best storage पर मतभेद:
- Epoch integers: सरल और तेज़, लेकिन epoch, units, और UTC का implicit knowledge चाहिए; metadata के बिना अस्पष्ट।
- ISO‑8601 strings: self‑describing और human‑readable, लेकिन धीमी और भारी।
- DB types: चेतावनी कि कुछ DBs में “TIMESTAMP WITH TIME ZONE” केवल UTC store करता है और original zone को discard कर देता है; अन्य लोग कहते हैं कि यह फिर भी उपयोगी है।
DST, offsets, और अजीब timezones
- प्रतिभागी कठिन वास्तविकताएँ गिनाते हैं: half‑hour और 45‑minute offsets, ऐतिहासिक अजीब offsets, बार‑बार होने वाले राजनीतिक बदलाव, DST shifts, duplicate hours.
- यह बात रखी गई कि future dates के लिए UTC↔local conversion एक स्थिर pure function नहीं है; आपको zone names और up‑to‑date tz databases चाहिए।
utcnow के बजाय क्या उपयोग करें & API design
- अनुशंसित pattern:
datetime.now(timezone.utc)(या समकक्ष), संभवतः serialization boundaries पर ही tzinfo हटाना। - कुछ लोग चाहते हैं कि Python में zoned बनाम zoneless datetimes के लिए अलग types हों (Java, Rust, Elixir की तरह) और “aware” को शुरू से default बनाया गया होता।
- अन्य लोग तर्क देते हैं कि Python में पहले से dynamic features और mocking हैं, इसलिए heavyweight abstractions (.NET के time provider जैसी) overkill हैं।
Backward compatibility और ecosystem impact
- चिंता है कि deprecation बड़े legacy और financial codebases को प्रभावित करेगी जिन्होंने naive UTC को standard बना रखा है।
- counterpoint: deprecation पहले, removal बाद में — semantics को silently बदलने से सुरक्षित है; static और runtime analysis call sites ढूँढ सकते हैं।
- Python की APIs तोड़ने की इच्छा 3.x में बनाम never‑break संस्कृतियों (C, Java) पर व्यापक बहस, और क्या “Python 4”‑style बड़े breaks की बजाय piecemeal changes बेहतर हैं।