Date जा रहा है, Temporal आ रहा है

 (piccalil.li)
6 पॉइंट द्वारा GN⁺ 2026-01-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • JavaScript के मौजूदा Date object की अपूर्णता और असंगतता की ओर इशारा करते हुए, उसे बदलने के लिए Temporal API का परिचय दिया गया है
  • Date एक mutable object की तरह काम करता है, इसलिए यह तारीख की वास्तविक अवधारणा से मेल नहीं खाता, और इसमें parsing errors·time zone handling limitations जैसी संरचनात्मक समस्याएँ हैं
  • Temporal immutability-आधारित नया date·time handling model देता है, जिसमें PlainDate, ZonedDateTime, Duration जैसी विभाजित classes शामिल हैं
  • Temporal के methods मौजूदा object को modify नहीं करते, बल्कि नया object return करते हैं, जिससे स्पष्ट और सुरक्षित chaining operations संभव होते हैं
  • Temporal अभी standardization Stage 3 में है, और Chrome व Firefox जैसे आधुनिक browsers में प्रयोगात्मक रूप से supported है

JavaScript के Date object की समस्याएँ

  • Date constructor असंगत parsing rules और गैर-सहज indexing की वजह से भ्रम पैदा करता है
    • उदाहरण: month 0 से शुरू होता है, लेकिन day और year 1 से शुरू होते हैं
    • string "99" को 1999 और "100" को 0100 के रूप में समझा जाता है, यानी consistency की कमी
  • Date को time केंद्रित तरीके से डिज़ाइन किया गया है और यह अंदरूनी रूप से Unix timestamp (milliseconds unit) के रूप में store होता है
  • time zone support सीमित है, और यह daylight saving time (DST) या non-Gregorian calendars को नहीं समझता
  • इन सीमाओं के कारण Moment.js, date-fns जैसी बड़ी third-party libraries पर निर्भरता आम हो गई है, जो performance degradation तक ले जाती है

Immutability और reference की अवधारणा का टकराव

  • JavaScript में primitive values immutable होते हैं और value के रूप में store होते हैं, लेकिन objects reference के रूप में store होते हैं और बदले जा सकते हैं
  • Date एक constructor से बनने वाला object है, इसलिए यह mutable है
    • उदाहरण: setMonth() या setDate() कॉल करने पर original object सीधे बदल जाता है
  • इसकी वजह से एक ही object को refer करने वाले variables के बीच अनपेक्षित value changes हो सकते हैं
    • उदाहरण: अगर today को argument के रूप में भेजी गई कोई function अंदर तारीख बदल दे, तो original today भी बदल जाता है

Temporal: नया date·time API

  • Temporal constructor नहीं बल्कि namespace object है, जिसकी संरचना Math जैसी है
    • मुख्य भाग: PlainDate, PlainDateTime, PlainTime, ZonedDateTime, Duration, Now आदि
  • Temporal.Now वर्तमान समय को कई रूपों में return करता है
    • plainDateISO() → ISO format की तारीख
    • zonedDateTimeISO() → time zone सहित समय
  • Temporal objects स्पष्ट method system प्रदान करते हैं
    • add({ days: 1 }), subtract({ years: 2 }) आदि से explicit unit operations किए जा सकते हैं
    • मौजूदा object को बदले बिना नया object return होता है, जिससे immutability बनी रहती है

Temporal कैसे काम करता है और इसके फायदे

  • Temporal objects अभी भी object type हैं, लेकिन ये जानबूझकर immutable usage pattern का पालन करते हैं
    • उदाहरण: today.add({ days: 1 }) नया date object return करता है, और original today नहीं बदलता
  • Date की तुलना में संक्षिप्त और स्पष्ट syntax देता है
    • उदाहरण: 
      const today = Temporal.Now.plainDateISO();  
console.log(`Tomorrow will be ${ today.add({ days: 1 }) }. Today is ${ today }.`);  
// 결과: Tomorrow will be 2026-01-01. Today is 2025-12-31.
  • time zone specification, duration calculation, ISO format retention जैसी आधुनिक ज़रूरतों के अनुरूप है
  • add, subtract, since, until जैसे method chaining से जटिल date calculations को संक्षिप्त रूप में व्यक्त किया जा सकता है

Standardization की स्थिति और आगे की दिशा

  • Temporal ECMAScript proposal Stage 3 तक पहुँच चुका है, यानी browser implementations के लिए अनुशंसित स्थिति में है
  • Chrome और Firefox में प्रयोगात्मक support शुरू हो चुका है, और दूसरे browsers भी इसे अपनाने वाले हैं
  • developers अभी से testing और feedback के जरिए specification सुधार में भाग ले सकते हैं
  • Date अभी भी रहेगा, लेकिन आगे चलकर Temporal के default date handling approach बनने की संभावना है
  • लेख का समापन इस बात से होता है कि “इसे 1995 में ही बदल देना चाहिए था, लेकिन अभी भी Temporal.Now के लिए यही सबसे सही समय है”

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-01-13
Hacker News की राय

  • यह लेख JavaScript के Date constructor के कई अजीब व्यवहारों पर बात करता है
    खासकर 'YYYY-MM-DD' फ़ॉर्मेट को UTC midnight के रूप में interpret किया जाता है, जिससे local timezone में तारीख एक दिन खिसक जाती है
    मूल ISO 8601 में timezone न दिया जाए तो उसे local time माना जाना चाहिए, लेकिन ES5 spec लिखते समय गलती से इसे “Z”(UTC) के रूप में handle किया गया
    बाद में ES2015 में इसे ठीक करने की कोशिश हुई, लेकिन बहुत-सी websites पहले से इसी गलत व्यवहार पर निर्भर थीं, इसलिए web compatibility के कारण इसे वापस ले लिया गया
    ज़्यादा जानकारी के लिए Broken Parser section देखें

    • अगर 'use strict' की तरह 'strict datetime' directive होता तो अच्छा रहता
      इससे पुराने code के साथ incompatibility पैदा किए बिना सही व्यवहार को चुनकर लागू किया जा सकता था
      या import Date from 'browser:date' की तरह किसी internal module से सुधारा गया global object लाया जा सकता था
    • मैंने भी पहले string को खुद split करके timezone-रहित date object बनाया था
      जन्मदिन जैसी चीज़, जो सिर्फ़ तारीख का मतलब रखती है, उसका timezone की वजह से बदल जाना बिल्कुल बेतुका है
      याद आता है कि Outlook पहले जन्मदिन को timezone सहित store करता था, इसलिए देश बदलने पर जन्मदिन एक-एक दिन खिसक जाता था
    • “web compatibility की वेदी पर बलि चढ़ा दिया गया” वाली अभिव्यक्ति काफ़ी प्रभावशाली लगी
      लेकिन क्या कोई बेहतर विकल्प था? पुराने IE5 दौर की तरह browser version के हिसाब से branching को मजबूर करना शायद उससे भी बदतर होता
    • jsdate.wtf साइट पर JS Date के अजीब व्यवहार सीधे देखे जा सकते हैं
    • यह सोचकर हँसी भी आती है और दुख भी, कि ऐसी चीज़ें अनगिनत छोटे bugs की जड़ बनती हैं

  • Rails और Ruby का time handling सच में ईर्ष्या पैदा करता है
    Time.current.in_time_zone('America/Los_Angeles') + 3.days - 4.months + 1.hour जैसी API intuitive और powerful लगती है
    Ruby, Time object को एक consistent object के रूप में overload करता है, इसलिए conversion या casting की चिंता बहुत कम रहती है
    JS में भी अगर new Date().add({ days: 1 }) जैसा सरल तरीका होता, तो कितना अच्छा होता

    • लेकिन “3.days - 4.months + 1.hour” जैसी syntax सच में अच्छी है या नहीं, इस पर सवाल उठाया गया
      और core library को overload करना सही approach है या नहीं, इस पर भी बहस की गुंजाइश है

  • अफ़सोस है कि Safari अभी तक Temporal API को support नहीं करता
    उम्मीद है कि अगले साल तक support आ जाए

  • JavaScript Date में समस्याएँ बहुत हैं, लेकिन object होना अपने-आप में कोई बड़ी समस्या नहीं है
    अगर यह immutable object होता तो बेहतर होता, लेकिन mutable object बदलेगा ही, इसमें हैरानी की बात नहीं

    • असली समस्या यह है कि कोई दूसरा code मेरे पास मौजूद Date object को चुपचाप modify कर सकता है
      mutability का असली ख़तरा local नहीं बल्कि non-local बदलाव में है

  • यह बात असुविधाजनक है कि Temporal API leap second की जानकारी को बिल्कुल handle नहीं करता
    कोई astronomical calculation के लिए JS tool बनाना चाहता हूँ, लेकिन UTC conversion के लिए leap second data चाहिए
    temporal-tai जैसा workaround है, लेकिन client side पर leap second file maintain करनी पड़ती है, जो झंझट है
    SOP(CORS policy) की वजह से बाहरी site से file सीधे लाना भी आसान नहीं
    browser नियमित रूप से update होते रहते हैं, फिर leap second जानकारी built-in क्यों नहीं होती, यह सवाल है

    • यह समझना गलत है कि SOP leap second file को रोकता है
      अगर server Access-Control-Allow-Origin header सेट करे या JS file के रूप में दे, तो यह संभव है
      हाँ, browser का खुद leap second data शामिल करके उसे maintain करना महँगा काम हो सकता है
    • “सिर्फ़ UTC handle करता है” कहना सटीक नहीं है
      UTC अपने स्वभाव में leap second शामिल करता है, इसलिए असल में कहना चाहिए कि यह सिर्फ़ POSIX time handle करता है

  • code example में "33" नहीं बल्कि "50" से 1900s में handle होना चाहिए — यह सिर्फ़ एक typo correction है

  • Temporal polyfill इस्तेमाल कर रहा हूँ, और अब तक अनुभव बहुत अच्छा रहा है

    • बस इसका size 51KB है, इसलिए इसे हल्का नहीं कहेंगे (bundlephobia link)
      server या बड़े app के लिए ठीक है, लेकिन छोटे app पर यह बोझ बन सकता है
    • moment या luxon से तुलना में यह कैसा है, इस पर सवाल भी आया

  • अजीब बात है कि लेख Date.now() का ज़िक्र ही नहीं करता
    Temporal से तुलना करनी हो तो Date.now() को आधार बनाकर समझाना चाहिए था
    यह function 1 जनवरी 1970 से बीते हुए milliseconds लौटाता है
    Temporal की API ज़्यादा friendly है, लेकिन मूल रूप से मकसद समय की relative distance दिखाना ही है

    • लेकिन लेख में बताए गए timestamp से जुड़े bugs भी मौजूद हैं
      तो सवाल है कि Date से गुज़रे बिना मनचाहे फ़ॉर्मेट में convert कैसे किया जाए

  • “daylight savings time” नहीं, “daylight saving time” सही है — यह छोटी लेकिन ज़रूरी correction है

  • अब तक पता ही नहीं था कि JS Date इतनी बुरी तरह टूटा हुआ है

    • और ज़्यादा दुखद यह है कि ये समस्याएँ 1995 से ही साफ़ दिखाई दे रही थीं
      अगर तब थोड़ी और सावधानी बरती गई होती, तो इतने developers इन जालों में नहीं फँसते