JavaScript Temporal आ रहा है

 (developer.mozilla.org)
2 पॉइंट द्वारा GN⁺ 2025-01-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • JavaScript का नया Temporal ऑब्जेक्ट ब्राउज़र की experimental releases में शामिल होना शुरू हो गया है, और इसका लक्ष्य date, time, duration और calendar handling को built-in API के ज़रिए अधिक सटीक और consistent बनाना है
  • मौजूदा Date में user local time और UTC-केंद्रित संरचना, अस्थिर parsing, और mutable behavior के कारण time zone handling और debugging मुश्किल रही है
  • Temporal, Temporal.Instant, Temporal.ZonedDateTime, Temporal.PlainDateTime, Temporal.Duration, Temporal.Now आदि के माध्यम से time point, local time, और duration को अलग करता है और 200 से अधिक utility methods देता है
  • स्थिर cross-browser support तक पहुँचने में अभी समय लगेगा, लेकिन Firefox Nightly में javascript.options.experimental.temporal सेटिंग के पीछे Temporal को आज़माया जा सकता है
  • MDN में इस हफ्ते Temporal पर 270 पेज से अधिक का documentation जोड़ा गया है, और @js-temporal/polyfill के साथ TC39 docs page पर flags बदले बिना examples चलाए जा सकते हैं

JavaScript Date की पुरानी सीमाएँ

  • जब JavaScript 1995 में बनाया गया था, तब Date ऑब्जेक्ट ने Java के शुरुआती java.util.Date implementation की नकल की थी। Java ने इसे 1997 में बदल दिया, लेकिन JavaScript ने लगभग 30 साल तक वही API बनाए रखा है
  • सबसे बड़ी समस्या time zone support की कमी और अस्थिर parsing behavior है
    • यह केवल user local time और UTC को support करता है
    • Date खुद mutable है, इसलिए यह ऐसे bugs पैदा कर सकता है जिन्हें trace करना कठिन हो
    • Daylight Saving Time(DST) और historical calendar changes के पार calculations संभालना भी मुश्किल है
  • इन सीमाओं की वजह से कई developers application में date और time handling के लिए Moment.js या date-fns जैसी dedicated libraries पर निर्भर रहे हैं

Temporal date और time model को कैसे बदलता है

  • Temporal को Date ऑब्जेक्ट के पूर्ण replacement के रूप में design किया गया है, और इसका लक्ष्य date व time management को अधिक reliable और predictable बनाना है
  • यह time zone और calendar representation को support करता है, और conversion, comparison, calculation, और formatting के लिए built-in methods देता है
  • API surface में 200 से अधिक utility methods हैं, और MDN के Temporal documentation में इनके descriptions और examples जोड़े गए हैं

Temporal के मुख्य types

  • Temporal unique time point, local wall-clock time, और duration को अलग-अलग types में विभाजित करता है
  • मुख्य संरचनाएँ इस प्रकार हैं
    • Temporal.Duration: दो time points के बीच का अंतर
    • Temporal.Instant: timestamp के रूप में व्यक्त unique time point
    • Temporal.ZonedDateTime: time zone सहित date और time
    • Temporal.PlainDateTime: time zone के बिना पूरा date और time
      • Temporal.PlainDate: केवल date
      • Temporal.PlainYearMonth: year और month
      • Temporal.PlainMonthDay: month और day
      • Temporal.PlainTime: केवल time
    • Temporal.Now: current time को अलग-अलग class instances या specific formats में पाने का API

उदाहरणों से उपयोग का तरीका

  • मौजूदा date और time को ISO string के रूप में पाया जा सकता है, और कई methods में time zone पास किया जा सकता है
    • Temporal.Now.plainDateTimeISO() system time zone का current date और time लौटाता है
    • Temporal.Now.plainDateTimeISO("America/New_York") New York time zone का current date और time लौटाता है
  • Gregorian के अलावा दूसरे calendars भी संभाले जा सकते हैं, इसलिए Hebrew, Chinese, Islamic जैसे calendar systems की dates बनाई जा सकती हैं
    • Chinese calendar के M01 1 दिन का उपयोग करके अगला Chinese New Year calculate किया जा सकता है
    • लेखन के समय example output में अगला Chinese New Year 1/29/2025 है
  • Unix Epoch millisecond timestamp को Temporal.Instant.fromEpochMilliseconds() से time point में बदला जा सकता है, और Temporal.Now.instant() से तुलना करके बचा हुआ समय निकाला जा सकता है
    • example timestamp 1851222399924 के लिए smallestUnit: "hour" के साथ अभी से बचा समय calculate किया जाता है
    • @js-temporal/polyfill output 31,600 hr देता है, जबकि Firefox Nightly output PT31600H है
  • Firefox implementation का toLocaleString अभी locale-sensitive string output नहीं देता
    • यह behavior तकनीकी सीमा से अधिक एक design decision के करीब है, और duration formatting खुद संभव है
    • polyfill और Firefox implementation बाद में एक-दूसरे के करीब आ सकते हैं
  • compare() method का उपयोग array sorting में किया जा सकता है
    • durations.sort(Temporal.Duration.compare) का उपयोग करने पर क्रम PT1H, PT1H30M, PT1H45M, PT2H बनता है

ब्राउज़र support और इसे आज़माने का तरीका

  • Temporal support experimental browser releases में धीरे-धीरे शामिल होना शुरू हुआ है, और फिलहाल Firefox implementation सबसे mature दिखाई देती है
  • Firefox में Nightly version पर javascript.options.experimental.temporal सेटिंग के पीछे Temporal build किया जा रहा है
  • implementation tracking के लिए प्रमुख browser issues ये हैं
  • पूरी compatibility status MDN के Temporal object Browser Compatibility section में देखी जा सकती है
  • TC39 Temporal documentation में @js-temporal/polyfill उपलब्ध है, इसलिए किसी भी browser में flags या settings बदले बिना developer tools console में examples चलाए जा सकते हैं

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

1 टिप्पणियां

 
GN⁺ 2025-01-31
Hacker News की राय

  • Temporal शानदार है। मैं कुछ समय से polyfill के साथ इसे production में इस्तेमाल कर रहा हूं, और यह पुराने Date() API में आने वाली कई समस्याओं को हल कर देता है।
    Rust के chrono, Java के Joda Time जैसी अच्छी time libraries से प्रेरणा लेकर उन्हें इस्तेमाल में आसान API में अच्छी तरह जोड़ दिया गया है—ऐसा लगता है।
    plain time, instant, और time zone सहित time को अलग-अलग रखने से यह थोड़ा ज्यादा जटिल जरूर है, लेकिन समय खुद जटिल है, इसलिए developers को उस जटिलता का सामना करना ही चाहिए।
    “इस timestamp में एक दिन जोड़ना है” जैसी चीज़ों में भी यह तय करना जरूरी है कि यह किस time zone के आधार पर है; वरना daylight saving time, user के time zone बदलने, या server time zone के फर्क की वजह से bugs रह जाते हैं।
    fixed offset timestamp (2025-01-01T00:00+02:00) और किसी खास time zone (Europe/Paris) के serialization के फर्क को भी यह हल कर देता है।

    • Rust crate Jiff भी देखने लायक है। यह Temporal से प्रेरित है, और chrono सहित दूसरी date-time crates से तुलना भी व्यवस्थित रूप से दी गई है: https://docs.rs/jiff/latest/jiff/_documentation/comparison/i...
      निजी तौर पर मुझे यह कहना मुश्किल लगता है कि Temporal ने Rust के chrono से बहुत ज्यादा प्रेरणा ली है; Joda या आजकल के java.time, और date-fns या Moment.js जैसी JavaScript date-time libraries का असर ज्यादा दिखता है।
    • थोड़ी उम्र/अनुभव वाले लोग बहुत पहले सीख चुके हैं कि production environment में local time 01:00 से 03:00 के बीच cron jobs schedule न करें।
    • बात सही है, लेकिन एक अड़चन है। बहुत से लोग वास्तविक location दिखाने वाले time zone names इस्तेमाल करना पसंद नहीं करते।
      वे यह देखने की कोशिश नहीं करते कि Europe/Paris France के बड़े हिस्से को बताता है या सिर्फ Paris को, और उन्हें ऐसा महसूस होता है जैसे वे कह रहे हों कि वे Paris में रहते हैं, जिससे वे चिढ़ जाते हैं।
      online community events schedule करते समय यह चीज़ काफी परेशान करने वाली रही है। लोग fixed offset इस्तेमाल करना चाहते हैं, और CET/CEST जैसी expressions उन्हें ठीक लगती हैं, लेकिन Europe/yourexactcoordinates जैसा कुछ पसंद नहीं आता।
      असल में ज्यादातर time zones काफी बड़े इलाकों को cover करते हैं, यह मुझे पता है, लेकिन privacy की चिंता करने के बावजूद “time” और “time zone” के फर्क को देखने की इच्छा न रखने वाले लोग बहुत हैं।
    • chrono और Joda Time अलग-अलग दौर की चीज़ें हैं। जब Rust 1.0 आया था, तब Java ने standard library के java.time में यह approach पहले ही implement कर दी थी, और इस काम के लिए third-party library की जरूरत नहीं थी।
    • fixed offset timestamp और किसी खास time zone timestamp के serialization में फर्क से कैसी समस्या आती है, यह मैं और विस्तार से जानना चाहूंगा।

  • docs में इसे ढूंढने में काफी समय लगा, लेकिन Temporal.ZonedDateTime.prototype.withTimeZone() एक time zone से दूसरे time zone में convert कर देता है: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    Temporal.ZonedDateTime.from("2021-08-01T12:00[America/New_York]") से बने value को withTimeZone("Europe/Paris") में डालने पर यह 2021-08-01T18:00:00+02:00[Europe/Paris] बन जाता है।
    time zone conversion और duration handling ऐसी core capabilities हैं जिन्हें library को जरूर संभालना चाहिए, और अच्छी बात है कि Temporal दोनों संभालता है। हालांकि Temporal.Duration में duration.format('H\hmm\m') जैसा custom format function नहीं दिखता, जिससे 1h03m बनाया जा सके।

    • DurationFormatter proposal यह control करने देता है कि किन units को किस level की abbreviation के साथ format करना है। उदाहरण के लिए 1 yr, 3 hours, 3m जैसे: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      मैंने icu4x library में इसका कुछ implementation किया था।

  • अभी TC39 में काफी सारे proposals पर काम पक रहा है, और Temporal उन चीज़ों में से है जिन्हें मैं जल्दी release होते देखना चाहूंगा
    मुझे पता है कि major browsers में नए features support करने के लिए v8, JSC और SpiderMonkey engineers की development मेहनत लगती है, इसलिए जो लोग progress करा रहे हैं उनका सच में आभारी हूं
    अधीर होने के नाते मन करता है कि कहूं, “Records और Tuples भी जल्दी कर दो! Pipe syntax की लड़ाई skip कर सकते हो!”

    • Records और Tuples के release होने की संभावना कम लगती है, या कम से कम उस equality semantics के साथ release होने की संभावना बहुत कम है जो लोग चाहते हैं
      मेरी समझ है कि browser vendors इस समय नए primitive types जोड़ने के खिलाफ पहले से ही काफी मजबूत विरोध में हैं। equality कैसे काम करनी चाहिए, इसकी मुश्किलें इस thread में समझाई गई हैं: https://github.com/tc39/proposal-record-tuple/issues/387
      मुझे शुरू में उम्मीद नहीं थी कि BigInt इतना ज्यादा इस्तेमाल होगा, लेकिन असल में structural equality वाली collections की जरूरत बार-बार पड़ती रहती है, इसलिए इसकी कमी खलती है
      मेरी जानकारी में नए primitive types जोड़ने का विरोध pattern matching को भी प्रभावित कर रहा है, लेकिन वजह मुझे ठीक से नहीं पता और उस proposal को मैं उतना follow नहीं कर रहा हूं
    • Temporal आ रहा है, यह अच्छी बात है और दूसरे अच्छे features भी बहुत हैं, लेकिन जिन खास proposals का जिक्र किया गया है, उन पर optimistic होना मुश्किल है
      pipelines, pattern matching, Records+Tuples—ये सभी 4 साल से ज्यादा समय से काम में हैं और अभी भी stage 1–2 पर अटके हैं। पिछले एक साल में meaningful progress pattern matching को छोड़कर शायद ही दिखी है
      Records और Tuples repository के issues के मुताबिक value semantics, यानी === काम कर सकता है या नहीं, इस पर pushback था। value semantics निकाल दें तो proposal की usefulness काफी घट जाती है
      इन्हें stage 3 तक पहुंचने में कम से कम 1–2 साल और लगेंगे, या शायद कभी न पहुंचें। फिर भी array grouping functions आ गए हैं
    • मैं जो चाहता हूं वह pattern matching है: https://tc39.es/proposal-pattern-matching/
      अभी यह stage 1 में है, इसलिए दुख की बात है कि इसमें शायद कुछ साल और लगेंगे
    • Records की बात हो तो, सोचता हूं कि Dictionary ECMA5 proposal था या AS3 का कोई अनोखा feature
      AS3 का Dictionary ऐसा type था जिसमें object references, strings और numbers को unique keys के रूप में इस्तेमाल किया जा सकता था और किसी भी type की value जोड़ी जा सकती थी। जब तक dictionary object खुद जीवित रहता था, garbage collection भी इस तरह handle होती थी कि वे weak references न रहें
      JavaScript के Set की तरह सोचिए, लेकिन जहां आप किसी भी तरह की specified key को strong type की तरह इस्तेमाल करते और compile time पर error मिलती। उस language की याद आती है
    • यह सिर्फ major browser makers की समस्या नहीं है। ES6 के आने के आसपास मैं JavaScript inference engine बना रहा था और ES5 को काफी support कर लिया था, लेकिन syntax updates की बाढ़ आने पर छोड़ना पड़ा
      उन updates ने असल में JavaScript ecosystem को बिगाड़ दिया, और अब लगता है कि सिर्फ वे languages बची हैं जो JS में compile होती हैं। जो लोग अभी भी vanilla JS लिखते हैं वे ऐसे लगते हैं जैसे assembly में apps बना रहे हों

  • मुझे जिज्ञासा है कि Temporal के अंदर हर time zone का data कैसे up-to-date रखा जाता है
    क्या structure ऐसा है कि TC39 कहीं data update करता है और हर browser उस data को internal copy करके नया version release करता है, या अगर user ने नए data वाले browser में update नहीं किया है तो मेरी website पर उसे गलत समय दिखेगा?
    उदाहरण के लिए Mexico ने 2022 में daylight saving time खत्म कर दिया था: https://en.wikipedia.org/wiki/Time_in_Mexico
    pytz या moment-timezone जैसी third-party libraries में server-side library update कर सकते हैं, और standard library handle करे तो language version upgrade कर सकते हैं, लेकिन Temporal और visitor के browser में यह कैसे होगा, समझ नहीं आता

    • Proposal document में “Time Zones and Resolving Ambiguity” पढ़ने पर सिर्फ इतना लिखा है कि IANA time zone database का इस्तेमाल होता है, यह नहीं बताया कि update कब होता है: https://tc39.es/proposal-temporal/docs/timezone.html
      user के computer को भी इस database तक access हो सकता है और शायद updates handle करता हो, लेकिन पक्का नहीं। browser अलग से इस database को download करके maintain भी कर सकता है, और लगता है implementation पर निर्भर करेगा
      संबंधित database: https://en.wikipedia.org/wiki/Tz_database
    • चूंकि यह browser में built-in feature होगा, शायद browser update के समय update होगा। browser vendors ने fast updates के लिए काफी काम किया है, और औसत user के computer पर browser शायद सबसे up-to-date रखा जाने वाला software होता है
    • browsers को Intl helpers की वजह से locales भी up-to-date रखने पड़ते हैं, इसलिए उस हिस्से की जांच करने पर शायद मिलता-जुलता जवाब मिल सकता है
    • Unix-like systems, यानी Linux distributions, macOS, Android में system-level IANA Time Zone Database की copy होती है। browser उसे use करता है या अपनी copy ship करता है, यह मुझे ठीक से नहीं पता, लेकिन Temporal निश्चित रूप से IANA tzdb use करता है
      अगर user ने नए time zone data को reflect करने के लिए browser या system update नहीं किया है, तो गलत समय दिख सकता है—यह बात कुल मिलाकर सही लगती है। हालांकि यह मौजूदा सामान्य practice से बहुत अलग नहीं है
      विकल्प यह है कि हर application अपना tzdb साथ रखे; कुछ apps ऐसा करते हैं और उसके valid कारण भी हो सकते हैं। लेकिन आम तौर पर यह wasteful है, applications के बीच inconsistencies बढ़ाता है, और update cycle भी धीमी होने की संभावना रखता है
    • यह implementation और system पर निर्भर करेगा। implementation को आखिरकार time zone provider define करना होगा, और संभव है कि यह engine implementation द्वारा Temporal को दिए जाने वाले host/system hooks से provide हो

  • जब कोई टाइम ज़ोन बदलता है, तो उसे detect करने वाला event जोड़ना चाहिए
    “समय के बारे में programmers के झूठे विश्वास” वाली सूची में “programmers मानते हैं कि इस्तेमाल के दौरान टाइम ज़ोन fixed रहता है” भी जोड़ा जा सकता है। असलियत में हर दिन लाखों लोग टाइम ज़ोन पार करते हैं

    • ऐसा event लोगों को fingerprint tracking करने और location का अनुमान लगाने के लिए एक और data point की तरह इस्तेमाल होगा
    • समझ नहीं आता कि यह event कहाँ काम आएगा। समय पर कुछ हद तक निर्भर ज़्यादातर web applications के लिए, प्रभावित users की संख्या देखते हुए, सीधे इस event को listen करके react करना इतना valuable होगा या नहीं, इस पर संदेह है
      हाँ, libraries के लिए मददगार हो सकता है
    • client का टाइम ज़ोन सिर्फ client के लिए ही मायने रखना चाहिए। timestamp को user के local time में दिखाने की सुविधा के अलावा ऐसी कोई condition नहीं है जहाँ client clock महत्वपूर्ण हो जाए। user टाइम ज़ोन बदल दे तो भी परवाह करने की वजह नहीं है
    • टाइम ज़ोन बदलाव track करने के लिए state चाहिए, इसलिए developers कैसे track और react करेंगे यह define करना ज़्यादा सही लगता है। शायद हम नहीं चाहेंगे कि Temporal उस handling के तरीके पर कोई राय रखे
    • अगर आप plane या ISS में हैं तो हो सकता है आपके पास कोई टाइम ज़ोन हो ही नहीं

  • .Now का function call न होना बहुत निराशाजनक है। यह property नहीं होनी चाहिए
    loop के अंदर .Now को कई बार evaluate करने पर हर बार अलग value आ सकती है, जो unexpected है
    C# ने भी यही choice की थी और नहीं करनी चाहिए थी: https://ericlippert.com/2014/05/19/when-should-i-write-a-pro...

    • लगता है आपने गलत समझा है। Now असली values लाने वाले functions का namespace है, जैसे Now.instant()

  • Temporal proposal सच में पसंद है, लेकिन एक बात खटकती है। comparison में यह reference equality पर निर्भर करता है
    यानी Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') होगा
    यह अपने-आप में बुरा नहीं है, लेकिन इन objects को Map keys के रूप में इस्तेमाल करने या Set में जमा करने की ability को लगभग खत्म कर देता है। मैं समझता हूँ कि यह फैसला क्यों लिया गया, लेकिन अफसोस है कि यह possible नहीं है
    शायद किसी दिन Records और Tuples सच में आ गए तो उन पर आधारित version मिल जाए

    • JavaScript के non-primitive types में क्या कोई ऐसा है जिसमें == reference के बजाय equality देता हो?
    • situation के हिसाब से .epochMilliseconds को Map/Set key या element के रूप में इस्तेमाल किया जा सकता है। लेकिन अगर Map में टाइम ज़ोन data preserve करना हो या Instant पर extra operations चाहिए हों, तो value side में original Instant preserve करना पड़ेगा
      Set के मामले में Map{v.epochMilliseconds:v} की तरह इस्तेमाल करके Instant preserve कर सकते हैं
      शानदार नहीं है, लेकिन यह Temporal से ज़्यादा JavaScript खुद की गलती है। runtime से handle करवाया जा सकता था, लेकिन तब polyfill fail हो जाएगा
    • भले ही यह possible हो, ऐसी values को Map/Set में इस्तेमाल करना floating-point numbers को Map/Set में इस्तेमाल करने जैसा है, इसलिए आम तौर पर बुरा idea है
    • क्या इसलिए नहीं कि JavaScript में यह possible नहीं है? Java के constant string pool की तरह कोई अजीब hack छोड़ दें, जहाँ इस्तेमाल होने वाला हर object पूरे object pool के अंदर की value का reference हो, तो यह मुश्किल है
    • बस String() या '2020-01-01' इस्तेमाल कर लें?

  • existing API के साथ काम करने वाला comparison function देना मजबूत design है। नया type जोड़ते समय इसे mandatory requirement मान लेने लायक है
    उदाहरण के लिए Temporal.Duration.compare को sort में pass करने पर PT1H, PT1H30M, PT1H45M, PT2H के order में sort कर सकते हैं। designers को सलाम

  • समझ आता है कि Temporal नाम शायद Moment, Datetime जैसे generic time objects से clash बचाने के लिए चुना गया है, लेकिन नाम अच्छा नहीं है
    पहली बार देखने पर लगा था कि यह garbage collection control जैसा कुछ होगा

    • temporal का मतलब eternity के विपरीत समय से जुड़ा हुआ, grammar tense या time distinction से जुड़ा हुआ, या space से अलग time से जुड़ा हुआ होता है: https://www.merriam-webster.com/dictionary/temporal
      सुनने में ठीक नाम लगता है
    • मुझे लगा browser के अंदर workflow engine Temporal है
    • यह पहले से लिए गए फैसले पर bike-shedding ही है, लेकिन मैं सहमत हूँ कि यह सच में खराब नाम है
      सबसे पहले, Temporal noun नहीं adjective है। समय से जुड़ा है, लेकिन intuitively फिट नहीं बैठता
      ज़्यादा महत्वपूर्ण बात यह है कि पुराने code से clash की संभावना कम करने के लिए अजीब नाम चुनने पर समय के साथ language और opaque होती जाती है
      Promise और Generator जोड़ते समय भी उन object names का इस्तेमाल करने वाली कई libraries थीं। reserved words के उलट built-in objects को overwrite किया जा सकता है, इसलिए यह बड़ा issue नहीं था
      standard committee को language की long-term health के लिए दृढ़ता से Time इस्तेमाल करना चाहिए था
      हालाँकि यह debate अब निकल चुकी है और browser makers व JS engine implementers सहमत हो चुके होंगे
    • मुझे भी यह भयानक नाम लगता है। इससे अच्छा DateV2 होता
      backward compatibility की जरूरत समझता हूँ, लेकिन Temporal का feel अच्छा नहीं है। DateTime तो JS standard में कोई name भी नहीं है, फिर उसे क्यों नहीं इस्तेमाल किया समझ नहीं आता। तब तक मैं const DateTime = Temporal रखूँगा

  • संबंधित पोस्ट:
    JavaScript Temporal Is Coming - https://news.ycombinator.com/item?id=42809834 - जनवरी 2025, 18 comments
    Mozilla: Temporal (Limited Availability) - https://news.ycombinator.com/item?id=42776548 - जनवरी 2025, 1 comment
    Is It Time for the JavaScript Temporal API? - https://news.ycombinator.com/item?id=29712118 - दिसंबर 2021, 100 comments
    Temporal: Getting started with JavaScript's new date time API - https://news.ycombinator.com/item?id=27661667 - जून 2021, 194 comments
    JavaScript Temporal - https://news.ycombinator.com/item?id=27395236 - जून 2021, 1 comment
    JavaScript Proposal Temporal for Dates is now stage 3 - https://news.ycombinator.com/item?id=26432346 - मार्च 2021, 1 comment

    • आजकल Web API वाकई शानदार हो गए हैं, इसके लिए शुक्रिया, लेकिन यह बात अब भी खलती है कि इस विषय की पहली submission लगभग 4 साल पहले, मार्च 2021 में हुई थी
      बड़े जहाज़ को दिशा बदलने में देर लगती है—यह बात बिल्कुल सही बैठती है