Python datetime pitfalls, and what libraries are (not) doing about it

मूल लेख ↗ Hacker News चर्चा ↗

सॉफ़्टवेयर में dates और times को संभालना “बस UTC इस्तेमाल करो” से कहीं ज़्यादा जटिल निकलता है, खासकर daylight saving time, बदलते time zone laws, और meetings या contracts जैसे भविष्य के human-facing events के मामले में। Commenters इस पर बहस करते हैं कि Python के `datetime` module और alternatives को समय को कैसे represent करना चाहिए—UTC instants, local “wall clock” times, fixed offsets, या full IANA time zones—और क्या libraries को ambiguous या non-existent times की अनुमति देनी चाहिए। बहुत से लोग इस निष्कर्ष पर पहुँचते हैं कि कोई एक model हर use case के लिए उपयुक्त नहीं है, इसलिए robust libraries को multiple explicit types और clear trade-offs चाहिए, न कि एक जादुई timestamp abstraction।

UTC बनाम स्थानीय समय और भविष्य की datetimes

  • कई लोग तर्क देते हैं कि “सब कुछ UTC में स्टोर करो” भूतकाल की घटनाओं और machine-centric timestamps के लिए अच्छी तरह काम करता है।
  • दूसरे ज़ोर देते हैं कि यह भविष्य के human-scheduled समयों (बैठकें, appointments, contracts) के लिए विफल हो जाता है।
  • मुख्य बात: भविष्य के wall-clock समय आम तौर पर (local datetime + IANA timezone) के रूप में स्टोर किए जाने चाहिए, pre-converted UTC के रूप में नहीं, क्योंकि timezone/DST नियम बदल सकते हैं।
  • कोई सार्वभौमिक नियम नहीं है: कभी users का मतलब fixed UTC instant होता है, कभी किसी स्थान पर “local wall time”।

DST, time zones, और human expectations

  • DST और timezone policy राजनीतिक होती है और बदल सकती है; आप भविष्य के नियमों की भविष्यवाणी नहीं कर सकते।
  • आवर्ती घटनाएँ (“हर सोमवार 10:00”, “हर दो हफ्ते 1 PM पर 1:1”) DST के दौरान एक घंटा शिफ्ट नहीं होनी चाहिए; इसके लिए local time और zones को स्पष्ट रूप से model करना पड़ता है।
  • अलग-अलग महाद्वीपों के बीच meetings में DST transitions अलग-अलग तारीख़ों पर होने के कारण अस्थायी misalignment होता है; calendars आम तौर पर एक reference zone चुनते हैं।

Data formats और epochs (ISO 8601, Unix time, आदि)

  • ISO 8601 / RFC 3339 string formatting में मदद करते हैं, लेकिन timezone/DST semantics या location की समस्या हल नहीं करते।
  • US-style MM/DD/YYYY और Excel जैसे tools को bugs के प्रमुख स्रोतों के रूप में देखा जाता है।
  • Unix epoch seconds (या integer micro/nanoseconds) internal representation के लिए लोकप्रिय हैं, लेकिन pre-1970 support और leap seconds tricky हैं।

Leap seconds

  • कुछ libraries (उदाहरण के लिए general-purpose ones, जिन पर चर्चा की गई है) leap seconds को ignore करती हैं; specialized ones (जैसे astronomy-focused) उन्हें handle करती हैं।
  • राय अलग-अलग है: कुछ के अनुसार अधिकांश apps के लिए leap seconds को ignore करना स्वीकार्य है; दूसरे ध्यान दिलाते हैं कि इससे precise duration/instant math और “23:59:60” parsing टूट जाती है।

Library design: types और behavior

  • अलग-अलग types के लिए मज़बूत समर्थन:
    • Instant/UTC-only,
    • ZonedDateTime (IANA zones),
    • OffsetDateTime (fixed offset),
    • Local/naive date-times wall-clock या recurring “alarm” use cases के लिए।
  • Naive और zoned data को एक ही type में जोड़ना (जैसा कुछ JS और Python libs में है) व्यापक रूप से आलोचित है।
  • DST gaps में nonexistent times को represent करने पर बहस:
    • कुछ invalid local times को disallow करने या error देने के पक्ष में हैं।
    • दूसरे documented, deterministic “best-effort” mappings को पसंद करते हैं, भले वे चौंकाने वाले हों।

“Local time” concept

  • कुछ लोगों का तर्क है कि system “local time” UI और libc-compat को छोड़कर एक ऐतिहासिक गलती है; बेहतर है हमेशा explicit time zones या locations specify की जाएँ।
  • दूसरे नोट करते हैं कि सामान्य users और devices को फिर भी alarms, cron-like tasks, और “cafe में 4pm” semantics के लिए local wall-clock time की धारणा चाहिए।