new Date("wtf") - आप JavaScript की Date class को कितना अच्छी तरह जानते हैं?

• यह क्विज़ JavaScript की Date class अलग-अलग input स्थितियों में कैसे व्यवहार करती है, इस पर केंद्रित है
• इसमें यह प्रयोग शामिल हैं कि जब उपयोगकर्ता की अपेक्षा से अलग input value (जैसे: "wtf" आदि) दी जाती है, तो Date class क्या result लौटाती है, exception होता है या नहीं, और अंदरूनी processing कैसे होती है
• इस क्विज़ के जरिए JavaScript Date के असामान्य क्षण, parsing strategy, standard non-compliance जैसी अप्रत्याशित behavior patterns को आसानी se समझा जा सकता है
• इसका उद्देश्य JavaScript developers और test engineers की समझ बढ़ाना है ताकि वे वास्तविक प्रोग्रामों में होने वाली date handling errors और अनिश्चितताओं को कम कर सकें

[GN⁺]

Hacker News टिप्पणियाँ

• मेरे firefox JS console में इस quiz से अलग जवाब आता है
• काश लोग JavaScript का मज़ाक उड़ाना बंद करें। पहले भी लोग ऐसा करते थे, फिर Node आया और अब यह पूरी दुनिया में फैल चुका है
  • मुझे लगता है TypeScript शायद उन भाषाओं में सबसे अच्छा विकल्प है जिन्हें पैसे कमाने के लिए इस्तेमाल किया जा सकता है
  • मुझे लगभग 10 साल तक चला वह WAT meme याद आता है, जहाँ लोग undefined behaviour को मानो टेक्नोलॉजी की निरर्थकता का निर्णायक सबूत मानते थे। असल में लोग सिर्फ टेक्नोलॉजी की अवधारणा को गलत समझ रहे थे। ईंट से पानी नहीं रखा जा सकता, यह कोई मज़ेदार बात नहीं है, लेकिन अजीब तरह से सबको उम्मीद थी कि JavaScript हर ~गलती~ को error बना देगा या खुद ठीक कर देगा। अच्छा लक्ष्य तो है, लेकिन अगर वह संभव न हो तो उस पर गर्व करना भी थोड़ा अजीब नज़रिया था। ऐसा माहौल बहुत लंबे समय तक बना रहा
• मुझे यह मज़ेदार quiz लगा। चौंकाने वाले behavior भी बहुत हैं। लेकिन असल में ज़्यादातर मामलों में यह इतना महत्वपूर्ण नहीं लगता। असल स्थिति में पहले यह सोचना चाहिए कि क्या आपको सच में local time चाहिए, और क्या instant इकाई में काम करना सही रहेगा। UTC ISO 8601 string या Unix timestamp इस्तेमाल करें तो ज़्यादातर complexity खत्म हो जाती है, या कम से कम software के कुछ हिस्सों तक सीमित रह जाती है। हाँ, हमेशा ऐसा नहीं होता (एक बार user के break time में 1 से 5 बजे के दो interval शामिल करने थे, और DST boundary पर यह बहुत दर्दनाक था)। फिर भी, मेरे अनुभव में ज़्यादातर मामलों में concern का दायरा कम करने का तरीका मिल जाता है। बिल्कुल बिना validation वाले user input को सीधे date parser में दे देना, usage का गलत तरीका है
  • क्योंकि user input को सही format में बदलने का तरीका ही parsing है, इसलिए language द्वारा दिए गए date parser को देना मुझे तर्कसंगत लगता है। यह ठीक से काम नहीं करता, यह बात JavaScript programmers के लिए ज़्यादा चौंकाने वाली नहीं होगी
  • "बिना validation वाले user input को date parser में नहीं देना चाहिए" — इससे मैं पूरी तरह सहमत हूँ। लेकिन अच्छे API और खराब API का फर्क यही है कि अच्छा API कुछ गड़बड़ होते ही fail हो जाए और बता दे, "तुम इसे गलत इस्तेमाल कर रहे हो"। ज़रा सा भी अजीब हो तो ठीक से fail होना चाहिए, किसी अजीब data को किसी तरह संभालने की कोशिश नहीं करनी चाहिए। मुझे लगता है बहुत से JS API इस तरह डिज़ाइन किए गए हैं कि वे चाहे कुछ भी हो, चलते रहें। मुझे न NaN चाहिए, न strings का आधा-अधूरा conversion
  • जब भी कोई कहता है, "बस UTC ISO 8601 string या Unix timestamp ही इस्तेमाल करो," तो मुझे लगता है कि ऐसे लोगों ने dates को बहुत सीमित तरीके से ही handle किया है। ज़रा future dates में इस strategy को लागू करके देखिए। उदाहरण के लिए, "शाम 7 बजे मिलते हैं" जैसी appointment में, daylight saving बदले या समय नियम बदलें, महत्वपूर्ण यह है कि मुलाकात 7 बजे ही हो। ऐसी चीज़ें वास्तविक दुनिया में अक्सर होती हैं। असल में मामला इससे भी सूक्ष्म है। कुछ apps में time zone context अनिवार्य होता है। मान लीजिए कोई service restaurant reservation दिखाती है, तो उसे user के local time में नहीं बल्कि restaurant के local time zone में दिखाना चाहिए। reservation का समय "वहाँ" का समय है, मैं अभी कहाँ हूँ यह महत्वपूर्ण नहीं। यानी GMT/UTC हर date problem की रामबाण दवा नहीं है। past dates के लिए यह ठीक समाधान हो सकता है, लेकिन तब भी user का local time या event के समय का actual time zone अलग से store करना कई बार उपयोगी होता है
  • मुझे लगता है DST offset को explicitly specify करने का option देना भी अच्छा तरीका है। कुछ परिस्थितियों में यह उपयोगी होता है। CSV इस्तेमाल करते समय Excel का format खुद infer न करना हमेशा मुझे confusing लगा है
  • मैं इस बात से सहमत हूँ। यह beginners के लिए आसानी से फँसने वाला trap है, और उम्मीद है इस quiz से कई लोग एक बार फिर इस पर सोचेंगे
• चौंकाने वाली बातें बहुत ज़्यादा हैं! कुल मिलाकर लगता है parser दिए गए input को किसी न किसी तरह date मानने के लिए जरूरत से ज़्यादा मेहनत करता है। चाहे उसकी interpretation बिल्कुल बिना सिद्धांत की हो, या इतनी अजीब कि इंसानी user भी उससे सहमत न हो, फिर भी वह जबरन कोई अर्थ देने की कोशिश करता है। जबकि असल में parse न कर पाने की स्थिति में error signal देने का तरीका मौजूद है, लेकिन उसका सक्रिय उपयोग नहीं होता। हाँ, शायद ये अजीब cases वास्तविक दुनिया के विचित्र use cases से आए हों
  • मुझे यह behavior predict करना ही असंभव लगता है। यह लगभग random noise जैसा है। 32-49 वाले strings को 2000s में पढ़ा जाता है, जबकि 50 के बाद उन्हें 1900s में interpret किया जाता है। ऐसे में तो सब कुछ हटाकर फिर से बनाना ही सही लगता है
  • हर हाल में valid result निकालने के लिए code लिखने की इच्छा मैं समझ सकता हूँ। लेकिन ज़्यादातर लोग उस impulse को रोक लेते हैं। यह डिज़ाइन करने वालों ने ऐसा क्यों नहीं किया, यही सोचता हूँ
  • यह phenomenon कुछ साल के अनुभव वाले developers में अक्सर दिखता है। junior developer सिर्फ errors देखकर किसी तरह चीज़ चलाने में व्यस्त रहता है। mid-level developer "हर हाल में error कम करो" mindset में फँसकर parser से बहुत ज़्यादा assumptions करवा देता है। वहीं से Date class जैसी चीज़ें पैदा होती हैं। senior developer ऐसे errors के खतरों को बहुत अच्छी तरह जानता है, और consistent व robust design करता है ताकि गलत input पर तुरंत error मिले
• 17/28 अंक मिले। सच में... ये श्रापित सवाल हैं! लगता है अब शायद इस Temporal stuff को भी एक बार देखना चाहिए
  • लगता है इसे release होने में वाकई बहुत समय लग रहा है। latest update पढ़ो तो थोड़ा मज़ेदार भी लगता है: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes
• 10/28 आया। इतना बुरा नहीं, लेकिन मुझे लगता है implementation के हिसाब से result अलग हो सकता है: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
  • मेरा 17/28 आया, लेकिन समझ नहीं आता इस पर गर्व करूँ या शर्मिंदा होऊँ। मैं खुद भी सोचता हूँ कि मुझे ऐसी चीज़ें पता ही क्यों हैं। मेरे बेटे को JS Date का ज़रा भी अनुभव नहीं है, फिर भी उसने पिछले जवाब देखकर अंदाज़ा लगाते हुए 11/28 ले लिया। type coercion क्या है, यह मैंने उसे समझाया। फिर लगा कहीं मैंने उसका IT career खराब तो नहीं कर दिया
  • सच में implementation पर निर्भर है। मैंने जानबूझकर quiz की शुरुआत में लिख दिया था कि इसे एक खास Node version और एक खास time zone में verify किया गया है; दोनों का result पर बड़ा असर पड़ता है
  • quiz की शुरुआत में मैंने देखा कि author ने अपने laptop का exact time zone भी लिखा था। जिन सवालों में मैं गलत हुआ, उनमें से एक शायद इसलिए था कि मैंने उस बात पर ध्यान नहीं दिया। यह पूरी तरह उचित explanation है। लगता है शुरू होने से पहले ही समझ जाना चाहिए था कि वही असली point होगा
• JS में dates के लिए मैं iso strings इस्तेमाल करता हूँ, क्योंकि इसमें खतरनाक traps बहुत हैं। (quiz के शुरुआती कुछ सवाल देख कर भी समझ आता है) Moment जैसी लोकप्रिय alternative libraries भी कई मायनों में उतनी ही problematic हैं। वे "date", "time", "datetime" जैसी अवधारणाओं को मिलाकर और ज़्यादा confusion पैदा करती हैं। मैंने यह तर्क भी सुना है कि "time" और "date" में कोई अलगाव होना ही नहीं चाहिए, लेकिन मेरे अनुभव से यह बिल्कुल मेल नहीं खाता
  • Moment, Luxon, Day.js जैसी मशहूर libraries अलग-अलग temporal concepts (absolute time, civil time आदि) को एक ही object में भर देने की गलती करती हैं। क्या absolute time और civil time सच में एक ही चीज़ हैं? इन्हें जबरन एक करने की कोशिश की जाती है
• मेरा score है... 28 नवंबर 2000... शायद
  • यह पढ़कर मैं काफ़ी देर तक हँसता रहा
• एक बात हमेशा सोचता हूँ कि यह सब हुआ कैसे। यह सचमुच ऐसा लगता है जैसे कई beginners ने जल्दी-जल्दी कुछ बना दिया हो, जिसमें हर तरफ inconsistent heuristics भरे पड़े हों और वे आपस में ठीक से मिल भी न सकें। लेकिन असल में यह beginners का काम नहीं रहा होगा, तो फिर स्थिति यहाँ तक पहुँची कैसे, यही जिज्ञासा है
  • दूसरे comments में भी आया है, Brendan Eich ने Twitter पर (लिंक) खुद कहा कि यह Java के Date class behavior की सीधी नकल थी। मेरे लिए यह historical context काफ़ी दिलचस्प है
  • असल में ज़्यादातर problem तब आती है जब dates से बिल्कुल असंबंधित अजीब strings को जबरन parse किया जाता है। यह लगभग edge case है। हाँ, edge case में भी बेहतर यही होता कि consistently error ही मिले, लेकिन जब तक आप user द्वारा डाला कोई भी random string सीधे Date.parse() में नहीं दे रहे, तब तक यह बहुत बड़ी समस्या नहीं बनती। व्यवहार में तो आप कोई specialized date library ही इस्तेमाल करेंगे। क्योंकि Date के अच्छे हिस्से भी इतने शानदार नहीं हैं
  • अगर किसी language में operator overriding हो सके या static typing न हो, तो अक्सर एक ही method को 10 अलग-अलग उद्देश्यों के लिए काम करना पड़ता है। Java या C++ में भी ऐसे inconsistent API काफ़ी हैं (हालाँकि JS जितना बुरा नहीं)
• JS quiz पर क्लिक करने में एक अलग मज़ा है, बस हँसने के लिए। 10 साल से ज़्यादा समय से JS इस्तेमाल कर रहा हूँ, लेकिन regex से validate किए बिना किसी string को Date में parse नहीं किया
  • तब आप दो समस्याएँ बना देते हैं
  • काफ़ी relatable है। मैंने 10 साल तक security-related JS code लिखा है। वह दौर था जब standard में बड़े updates आ रहे थे। हमारा system browser-agnostic consistency और predictability के लिए JS का बहुत ही छोटा subset इस्तेमाल करता था। standard बदलने के बाद भी हमने सिर्फ array.filter और structuredcopy जोड़ा, बाकी सबको नज़रअंदाज़ किया क्योंकि उनसे कोई वास्तविक फ़ायदा नहीं था, सिर्फ attack surface बढ़ती थी। फिर TypeScript आया, और मुझे लगा यह JS इतिहास की सबसे बड़ी missed opportunity थी। आज भी JS में सही तरीके से coding करने का मतलब है कि आप भाषा का सिर्फ 1% बहुत सावधानी से इस्तेमाल करें। और उस 1% को भी बहुत सोच-समझकर इस्तेमाल करना पड़ता है