JavaScript की समय समस्या को हल करने वाले 9 साल के सफर का नाम: Temporal

(bloomberg.github.io)

13 पॉइंट द्वारा GN⁺ 2026-03-12 | 7 टिप्पणियां | WhatsApp पर शेयर करें

JavaScript के Date object की सीमाओं को मूल रूप से बदलने वाला नया मानक Temporal API, 9 साल के विकास के बाद ECMAScript Stage 4 तक पहुंच गया
Temporal immutable types, स्पष्ट time zone और calendar support, और nanosecond-level precision देता है, जिससे मौजूदा Date की अस्पष्टता और त्रुटियां दूर होती हैं
Bloomberg, Igalia, Microsoft, Google, Mozilla सहित कई संगठनों ने specification design और implementation पर साथ काम किया, और Rust-आधारित साझा लाइब्रेरी temporal_rs के जरिए multi-engine collaboration संभव हुआ
Temporal, ZonedDateTime, Instant, PlainDate/Time, Duration जैसे अधिक सूक्ष्म types के जरिए time operations और internationalized calendar handling को सटीक रूप से support करता है
30 साल पुरानी समस्याओं को हल करने वाला यह मानक, JavaScript ecosystem में collaboration और open innovation की एक सफल मिसाल माना जा रहा है

JavaScript में time handling की समस्या और Temporal का आगमन

मौजूदा Date object को 1995 में Java के Date से लगभग ज्यों-का-त्यों port किया गया था, और mutability, असंगत month calculation, अस्पष्ट parsing जैसी समस्याओं के कारण यह दशकों से bugs की वजह बना रहा
- उदाहरण: setMonth इस्तेमाल करने पर महीने के अंत की गणना में त्रुटि, ISO-जैसी strings की parsing में browser के अनुसार अलग परिणाम
2010 के दशक के बाद web applications जटिल होने लगीं, तो Date की सीमाएं और गंभीर हो गईं
डेवलपर्स ने Moment.js जैसी बाहरी libraries से इन समस्याओं की भरपाई की, लेकिन इससे bundle size बढ़ा और maintenance burden भी आया
2017 में Maggie Johnson-Pint ने TC39 में Temporal proposal जमा किया, जिसके साथ standardization पर चर्चा शुरू हुई

TC39 और industry का collaboration

Temporal ने 2018 में Stage 1 से शुरुआत की और 9 साल में Stage 4 (standardization) तक पहुंचा
Bloomberg ने बड़े JavaScript environments में time zone और precision से जुड़ी समस्याओं को हल करने के लिए सक्रिय भूमिका निभाई
- आवश्यकताएं: custom time zones, IANA-आधारित historical time zone accuracy, nanosecond-level precision
Igalia, Microsoft, Google, Mozilla आदि के साथ मिलकर specification design और implementation आगे बढ़ाया गया
Philipp Dunkel, Ujjwal Sharma, Philip Chimento, Shane Carr, Justin Grant सहित कई engineers ने champions के रूप में भाग लिया

Temporal के प्रमुख types और features

Temporal.ZonedDateTime: स्पष्ट time zone, calendar, और DST adjustment के साथ immutable समय-प्रस्तुति
- उदाहरण: London में DST transition के दौरान अगर 01:30 मौजूद न हो, तो इसे अपने-आप 02:30 पर adjust किया जाता है
Temporal.Instant: time zone और calendar के बिना absolute time point, nanosecond-level precision के साथ
- एक ही समय-बिंदु को कई time zones में बदला जा सकता है
PlainDate / PlainTime / PlainDateTime / PlainYearMonth / PlainMonthDay: time zone के बिना 'wall-clock' प्रकार
- साधारण तारीख/समय दिखाने या गणना के लिए उपयुक्त
Temporal.Duration: समय-अंतराल की अभिव्यक्ति, अलग-अलग units में conversion संभव (total({ unit: "second" }))
Calendar support: Hebrew calendar जैसी non-Gregorian calendars पर भी सटीक operations

implementation और standardization की प्रक्रिया

Temporal, ECMAScript के इतिहास में specification का सबसे बड़ा addition है, जिसमें लगभग 4,500 test cases शामिल हैं
Rust-आधारित shared implementation temporal_rs विकसित की गई, जिसे V8, Boa सहित कई engines ने साझा रूप से इस्तेमाल किया
- फायदे: entry barrier कम, long-term maintenance आसान, code quality बेहतर
2024~2025 के दौरान temporal_rs ने 100% tests pass किए, और इसे multi-engine collaboration की एक सफल मिसाल माना गया

support की स्थिति और आगे की चुनौतियां

Temporal को पहले से Firefox 139, Chrome/Edge 144, TypeScript 6.0 Beta में support मिला हुआ है
- Safari अभी technology preview चरण में है, Node.js 26 बाद में आने वाला है
आगे की मुख्य चुनौती web APIs के साथ integration है
- उदाहरण: <input type="date"> जैसे form elements में Temporal type support
- DOMHighResTimeStamp के विकल्प के रूप में इसकी संभावना पर विचार (Temporal.Now.instant() के उपयोग का उदाहरण)

collaboration और open innovation की उपलब्धि

Temporal, 9 साल के multi-organization collaboration से बना मानक है,
- जिसमें Microsoft, Google, Mozilla, Bloomberg, Igalia, Boa जैसे कई पक्ष शामिल रहे
temporal_rs, shared infrastructure model की एक सफल मिसाल है,
- जिसने दोहराए गए implementation cost को घटाने, consistency बढ़ाने और innovation तेज करने को साबित किया
Temporal को सिर्फ API improvement नहीं, बल्कि JavaScript community द्वारा लंबे समय से जमा technical debt को मिलकर हल करने के प्रमाण के रूप में देखा जा रहा है
30 साल बाद JavaScript को आखिरकार एक आधुनिक date/time API मिल गया

7 टिप्पणियां

jeeeyul 2026-03-12

समय की गणना की जटिलता सिर्फ फ़ॉर्मैट की समस्या नहीं है; यह उससे कहीं ज़्यादा मानव दर्शन, खगोलशास्त्र की सटीकता और संस्कृति से आती है। गणना तो सिर्फ long से भी आसान है। ऐतिहासिक रूप से टाइमलाइन में ऐसे कई अजीब हिस्से तय किए गए हैं जहाँ 1 + 1, 2 नहीं होता, और इसका बड़ा कारण उन कैलेंडर प्रणालियों में है जो सूर्य और पृथ्वी की सतह के कोण जैसी स्थितियों के हिसाब से बदलती हैं। ऐसे मामलों में, किसी भी स्थिति में कोरियाई सौर-चंद्र कैलेंडर पर तो कभी चर्चा तक नहीं हुई।

और वह कोरिया खगोल एवं अंतरिक्ष विज्ञान संस्थान तय करता है.

tsboard 2026-03-12

आख़िरकार! बहुत मज़ेदार!!

shakespeares 2026-03-12

आख़िरकार!!

roxie 2026-03-12

ZonedDateTime...? तुम कहीं...!

sea715 2026-03-12

आख़िरकार

click 2026-03-12

C की `time.h` -> Java की `java.util.Date` -> js का `Date`

Java का joda-time -> JSR 310 -> java.time
-> moment.js -> js Temporal

तो यह ऐसा प्रवाह है।

GN⁺ 2026-03-12

Hacker News की राय

मुझे यह बहुत पसंद है कि Temporal time handling की जटिलता को सही तरीके से संभालने के लिए मजबूर करता है
instant और calendar-based datetime के बीच का फर्क Date में होने वाली आम गलतियों को लगभग रोक देता है
यह थोड़ा verbose है, लेकिन सुबह 3 बजे DST bug ठीक करने के लिए बुलाए जाने से कहीं बेहतर है
- तकनीकी रूप से कहें तो, सुबह 3 बजे DST bug ठीक करने की नौबत रविवार के अलावा शायद ही कभी आएगी
मैंने भी Python में ISO8601 date parsing की समस्या के कारण लगभग 10 साल की परेशानी झेली है
2012 में शुरू हुआ issue आखिरकार standard library में समाधान के रूप में शामिल हुआ
संबंधित चर्चा इस Google Groups थ्रेड में देखी जा सकती है
- दिल से धन्यवाद। fromisoformat के अलावा किसी और तरीके से date parse करना अब बहुत गैर-सहज लगता है
  पहले मैं ciso8601 इस्तेमाल करता था, लेकिन standard में आने के बाद सब कुछ काफी सरल और स्थिर हो गया है
Firefox ने spec stage में Temporal को implement कर लिया था, इसका श्रेय André Bargull(Anba) को जाता है,
और यह बात खास तौर पर प्रभावशाली है कि उन्होंने असल में पूरा implementation अकेले स्वयंसेवक के रूप में किया
Temporal एक बड़ी प्रगति है, लेकिन फिर भी मुझे API पसंद नहीं है
मैं client और server के बीच code share करता हूँ, इसलिए data और logic को सख्ती से अलग रखने की कोशिश करता हूँ
मैं चाहता हूँ कि सारा data pure JSON में रहे ताकि serialization/deserialization आसान रहे, लेकिन Temporal object function properties वाले class instances हैं, इसलिए असुविधा होती है
मुझे लगता है कि date-fns की तरह data-only objects पर pure functions लागू करने का तरीका बेहतर है
- यह जानबूझकर किया गया design है। Temporal types serialize किए जा सकते हैं, लेकिन JSON.parse से अपने-आप restore नहीं होते
  developer को ISO string से सही object खुद reconstruct करना चाहिए
  इसे automate करने पर गलत type handle करने का जोखिम रहता है
  docs में Temporal.Instant reviver उदाहरण उपयोगी हो सकता है
- मुझे भी यही समस्या अक्सर होती है। JSON.parse/stringify से prototype का गायब हो जाना एक आम issue है
  लेकिन मुझे लगता है Temporal team का फैसला सही है। date-time logic में simple data + function approach से ज्यादा type safety महत्वपूर्ण है
  operations को object से बाँधने पर PlainDate को गलती से ZonedDateTime की तरह treat होने से रोका जा सकता है
  tRPC जैसी जगहों पर boundary पर Temporal.from() और toString() convert करने वाली एक पतली layer जोड़ना काफी है
  यह थोड़ा झंझट भरा है, लेकिन type safety छोड़ने से बेहतर है
- असल में JavaScript के Date instances में भी यही समस्या है
  Date.toJSON है, लेकिन JSON parsing के समय string को फिर से Date में बदलना पड़ता है
  Temporal में भी यही है, और date-fns भी आखिरकार native Date instances को ही संभालता है
- सभी Temporal objects को .toString() और Temporal.from() से आसानी से serialize/deserialize किया जा सकता है
- JSON.parse को अपने-आप Temporal objects बनाने के लिए बदलना मुझे हद से ज़्यादा लगता है
  Date की तरह
```
serialize: instant.toJSON()
deserialize: Temporal.Instant.from(jsonDate)
```
  इस तरह explicitly handle करना ही सही है
Temporal के approve होने से मैं बहुत खुश हूँ
लंबे समय तक मेहनत करने वाले सभी champions को बधाई
पिछले कुछ वर्षों में temporal_rs पर काम करते हुए बहुत आनंद आया
Java के time API improvement journey (Joda-Time → JSR 310 → Java 8) का साथ में ज़िक्र होता तो दिलचस्प होता
क्योंकि JavaScript का radical proposal 2018 में आया था, इसलिए जिज्ञासा है कि Java के approach का कुछ असर पड़ा होगा या नहीं
- सही बात यह है कि Joda ने Moment.js को प्रभावित किया, और वह आगे चलकर TC39 की चर्चाओं में भी झलका
  TC39 ने दूसरी भाषाओं की मिसालों को देखा, लेकिन सहमति JavaScript के लिए optimized दिशा में बनी
  मुझे लगता है यह API 9 साल में JS experts द्वारा design किया गया सबसे परिपक्व implementation है
- सही है, JavaScript ने भी Java से Date का एक खराब version उठा लिया था
  इससे जुड़ी बात इस HN थ्रेड में भी देखी जा सकती है
“Mocha के दौर में Ken Smith ने Java के Date code को C में port किया था” यह बात मजेदार है
क्योंकि Java का util.Date खुद लगभग C के time.h API का port था
Safari के Temporal को partial support देने की बात देखकर हँसी आई
अब Safari मानो IE का आध्यात्मिक उत्तराधिकारी बन गया है
- Safari नए features अपनाने में धीमा है, लेकिन फिर भी लगातार implement कर रहा है
  IE की समस्या सिर्फ धीमापन नहीं थी, बल्कि dominant position में रुक जाना थी
  अभी Chrome साम्राज्य की सीट पर है, और उल्टा Safari और Firefox की ज़रूरत ज्यादा है
  Chrome-only sites का बढ़ना ही असली समस्या है
- 2026 आ जाने पर भी शायद mobile Safari में native date picker नहीं होगा

काश Temporal में interval type होता

const D = new Temporal()
const t = new Interval({minutes:5})
const v = D.add(t)

वह Duration है

const D = Temporal.PlainDate.from("2020-06-16");
const t = Temporal.Duration.from({ day: 1 });
const v = D.add(t) // 2020-06-17

MDN docs देखें

हाँ, उसे Duration ही कहते हैं

इसके लिए 9 साल तक 1x speed पर time travel करने वाली टीम का धन्यवाद