new Date("wtf") - คุณรู้จักคลาส Date ของ JavaScript ดีแค่ไหน?

• แบบทดสอบนี้มุ่งเน้นไปที่การทำงานของ คลาส Date ใน JavaScript ภายใต้สถานการณ์อินพุตที่หลากหลาย
• มีเนื้อหาการทดลองเกี่ยวกับผลลัพธ์ที่คลาส Date ส่งกลับเมื่อได้รับค่าอินพุตที่ผู้ใช้อาจไม่คาดคิด (เช่น "wtf") การเกิดข้อยกเว้นหรือไม่ และวิธีการประมวลผลภายใน
• ผ่านแบบทดสอบนี้ คุณจะเข้าใจได้ง่ายถึง ช่วงเวลายกเว้น, กลยุทธ์การพาร์ส, การไม่เป็นไปตามมาตรฐาน และรูปแบบพฤติกรรมที่ไม่คาดคิดของ JavaScript Date
• มีจุดประสงค์เพื่อช่วยเพิ่มความเข้าใจให้กับนักพัฒนา JavaScript และผู้รับผิดชอบการทดสอบ เพื่อลด ข้อผิดพลาดในการจัดการวันที่ และความไม่แน่นอนที่อาจเกิดขึ้นในโปรแกรมจริง

[GN⁺]

ความคิดเห็นบน Hacker News

• ในคอนโซล JS ของ firefox ฉันได้คำตอบไม่เหมือนกับในควิซนี้
• อยากให้เลิกเอา JavaScript ไปเป็นตัวตลกสักที สมัยก่อนคนก็ทำแบบนั้นกัน แล้วสุดท้าย Node ก็ออกมาและตอนนี้มันก็แพร่ไปทั่วโลกแล้ว
  • ฉันคิดว่า TypeScript น่าจะเป็นตัวเลือกที่ดีที่สุดในบรรดาภาษาที่ใช้ทำงานหารายได้ได้
  • มันทำให้นึกถึงมีม WAT ที่คนมอง undefined behaviour มานานเกือบ 10 ปี ราวกับเป็นหลักฐานชี้ขาดว่าเทคโนโลยีนั้นไร้ความหมาย ทั้งที่จริงแล้วแค่คนเข้าใจแนวคิดของเทคโนโลยีผิดไปเอง การเอาอิฐไปใช้ตักน้ำไม่ได้ไม่ใช่เรื่องน่าขำ แต่แปลกที่ทุกคนกลับคาดหวังว่า JavaScript จะต้องจับ ~ความผิดพลาด~ ทุกอย่างเป็น error หรือแก้ให้เองได้ทั้งหมด มันเป็นเป้าหมายที่ดีนะ แต่ถ้าทำไม่ได้ก็ไม่ควรเอามาโอ้อวดเหมือนกัน ฉันรู้สึกว่าบรรยากาศแบบนี้ยืดเยื้อมานานเกินไป
• คิดว่าเป็นควิซที่สนุกนะ มีพฤติกรรมที่ทำให้ตกใจอยู่เยอะ แต่ในโลกจริงส่วนใหญ่รู้สึกว่าไม่ได้สำคัญขนาดนั้น ในสถานการณ์จริงควรคิดก่อนว่าคุณจำเป็นต้องใช้เวลาท้องถิ่นจริงหรือเปล่า และควรใช้ในระดับ instant ไหม ถ้าใช้สตริง UTC ISO 8601 หรือ Unix timestamp ความซับซ้อนส่วนใหญ่จะหายไป หรืออย่างน้อยก็ต้องไปกังวลแค่บางส่วนของซอฟต์แวร์ แน่นอนว่าไม่ใช่ทุกกรณี (ครั้งหนึ่งฉันเคยต้องรองรับช่วงเวลาพักของผู้ใช้ที่ต้องครอบคลุมสองช่วงคือ 1–5 นาฬิกา แล้วตรงขอบเขต DST นี่ทรมานมาก) แต่ส่วนใหญ่จากประสบการณ์แล้วมักหาวิธีลดขอบเขตที่ต้องใส่ใจได้ ถ้าคุณส่งข้อมูลที่ผู้ใช้กรอกมาแบบไม่ตรวจสอบอะไรเลยเข้าไปให้ date parser ตรง ๆ นั่นคือใช้มันผิดวิธี
  • เพราะการแปลงข้อมูลที่ผู้ใช้ป้อนให้เป็นรูปแบบที่ถูกต้องก็คือ การพาร์ส อยู่แล้ว ฉันเลยคิดว่าการส่งต่อให้ date parser ที่ภาษามีมาให้เป็นเรื่องสมเหตุสมผล และการที่มันทำได้ไม่ดีนักก็ไม่ใช่เรื่องน่าแปลกใจสำหรับโปรแกรมเมอร์ JavaScript
  • เห็นด้วยเต็มที่กับคำว่า "ห้ามส่งข้อมูลผู้ใช้ที่ยังไม่ตรวจสอบเข้า date parser" แต่ความต่างระหว่าง API ที่ดีกับ API ที่ไม่ดีคือ API ที่ดีจะล้มเหลวทันทีเมื่อมีอะไรผิดปกติ และบอกคุณว่า "คุณกำลังใช้งานผิด" ถ้ามีอะไรแปลกแม้แต่นิดเดียวมันก็ควร fail อย่างถูกต้อง ไม่ใช่พยายามฝืนตีความข้อมูลประหลาด ๆ ฉันคิดว่าปัญหาคือ API ของ JS จำนวนมากถูกออกแบบมาให้ทำงานต่อให้ได้ไม่ว่าอะไรจะเกิดขึ้น ฉันไม่ต้องการได้ NaN และไม่ต้องการการแปลงสตริงแบบกึ่ง ๆ กลาง ๆ ด้วย
  • ทุกครั้งที่ได้ยินคนพูดว่า "ใช้แค่สตริง UTC ISO 8601 หรือ Unix timestamp ก็พอ" ฉันจะรู้สึกว่าคนพวกนั้นน่าจะเคยจัดการวันที่ในรูปแบบจำกัดมาก ๆ เท่านั้น ลองคิดดูว่าถ้าใช้กลยุทธ์แบบนั้นกับวันเวลาในอนาคตจะเป็นยังไง เช่น การนัดว่า "เจอกันหนึ่งทุ่ม" สิ่งสำคัญคือได้เจอกันตอนหนึ่งทุ่ม แม้เวลาออมแสงหรือเวลาอย่างเป็นทางการจะเปลี่ยนไป เรื่องแบบนี้เกิดขึ้นจริงค่อนข้างบ่อย จริง ๆ แล้วมันเป็นปัญหาที่ละเอียดอ่อนกว่านั้น บางแอปจำเป็นต้องมีบริบทของเขตเวลาเสมอ เช่น ถ้าเป็นบริการแสดงการจองร้านอาหาร ก็ควรแสดงตามเวลาท้องถิ่นของร้าน ไม่ใช่เวลาท้องถิ่นของผู้ใช้ เวลาจองสำคัญที่เวลา "ที่นั่น" ไม่ใช่ว่าตอนนี้ฉันอยู่ที่ไหน ดังนั้น GMT/UTC ไม่ใช่ยาครอบจักรวาลสำหรับปัญหาเรื่องวันที่ทั้งหมด ถ้าเป็นวันเวลาในอดีตก็เป็นทางออกที่ดี แต่ถึงอย่างนั้นหลายครั้งก็ยังมีประโยชน์ที่จะเก็บเวลาท้องถิ่นของผู้ใช้หรือเขตเวลาตอนที่อีเวนต์เกิดขึ้นไว้ต่างหาก
  • ฉันคิดว่าการมีตัวเลือกให้ระบุ DST offset แบบชัดเจนก็น่าจะเป็นแนวทางที่ดีเหมือนกัน ขึ้นอยู่กับสถานการณ์ว่ามีประโยชน์แค่ไหน ฉันสับสนมาตลอดเหมือนกันที่ Excel เวลาใช้ CSV แล้วไม่เดาฟอร์แมตเอง
  • เห็นด้วยกับเรื่องนี้ มันเป็นกับดักที่มือใหม่พลาดได้ง่าย หวังว่าควิซนี้จะทำให้หลายคนกลับมาคิดเรื่องนี้อีกครั้ง
• มีส่วนที่น่าประหลาดใจเยอะมาก! โดยรวมแล้วฉันคิดว่าพาร์เซอร์พยายามมากเกินไปที่จะตีความอินพุตที่ได้รับให้เป็นวันที่ให้ได้ ไม่ว่าการตีความนั้นจะไร้หลักการมากแค่ไหน หรือประหลาดจนแม้แต่มนุษย์ที่เห็นก็ยังไม่เห็นด้วย มันก็ดูเหมือนจะยัดความหมายให้จนได้ ทั้งที่ในกรณีที่ตีความไม่ได้จริง ๆ ก็ยังมีวิธีส่งสัญญาณ error ได้ แต่กลับไม่ค่อยใช้สิ่งนั้นอย่างจริงจัง แน่นอนว่าเคสแปลก ๆ เหล่านี้อาจมาจากกรณีใช้งานประหลาด ๆ ในโลกจริงก็ได้
  • ฉันรู้สึกว่าพฤติกรรมแบบนี้คาดเดาไม่ได้เลย มันแทบจะเป็นสัญญาณรบกวนแบบสุ่ม สตริงหมายเลข 32–49 ถูกตีความเป็นปี 2000 กว่า แต่หลังจาก 50 เป็นต้นไปกลับถูกตีความเป็นปี 1900 กว่า แบบนี้ควรทุบทิ้งแล้วสร้างใหม่ทั้งหมด
  • ฉันเข้าใจความอยากเขียนโค้ดให้คืนค่าที่ valid ออกมาเสมอ แต่คนส่วนใหญ่มักยับยั้งแรงกระตุ้นนั้นได้ เลยสงสัยว่าคนที่ออกแบบสิ่งนี้ทำไมถึงยับยั้งไม่ได้
  • ปรากฏการณ์นี้เป็นปัญหาที่พบได้บ่อยในหมู่นักพัฒนาที่มีประสบการณ์มาสักไม่กี่ปี นักพัฒนาจูเนียร์เห็นแต่ error แล้วก็พยายามทำให้มันพอทำงานได้ก่อน นักพัฒนาระดับกลางจะยึดติดกับแนวคิดว่า "ต้องลด error ให้ได้ทุกกรณี" จนพาร์เซอร์ตั้งสมมติฐานมากเกินไป เลยได้อะไรแบบคลาส Date ออกมา ส่วนนักพัฒนาระดับซีเนียร์รู้ซึ้งถึงความเสี่ยงของ error แบบนี้ จึงออกแบบให้สม่ำเสมอและ robust และให้ข้อมูลที่ผิดพลาดเกิด error ทันที
• ได้ 17/28 คะแนน คิดว่าเป็นโจทย์ที่...ต้องคำสาปจริง ๆ! ตอนนี้คงถึงเวลาต้องไปดู Temporal stuff นี้สักทีแล้วมั้ง
  • ดูเหมือนมันจะใช้เวลานานมากกว่าจะออกจริง อ่านอัปเดตล่าสุดแล้วแอบขำหน่อย ๆ: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes
• ฉันได้ 10/28 ก็ไม่เลวนะ แต่คิดว่าผลลัพธ์อาจต่างกันไปตาม implementation: 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 ให้เขาฟัง แล้วก็เลยแอบคิดว่าตัวเองกำลังขัดขวางเส้นทางอาชีพสายไอทีของลูกหรือเปล่า
  • มันต่างกันตาม implementation จริง ๆ ฉันเลยตั้งใจเขียนไว้ตั้งแต่ต้นควิซว่าได้ทดสอบกับ Node เวอร์ชันหนึ่งและเขตเวลาหนึ่งโดยเฉพาะ ซึ่งทั้งสองอย่างมีผลต่อผลลัพธ์มาก
  • ฉันเห็นว่าผู้เขียนระบุเขตเวลาของแล็ปท็อปตัวเองไว้อย่างชัดเจนตั้งแต่ต้นควิซ คิดว่าหนึ่งในข้อที่ฉันตอบผิดก็น่าจะเพราะไม่ได้ใส่ใจตรงนั้น ซึ่งถือว่าเป็นคำอธิบายที่สมเหตุสมผล และทำให้รู้สึกว่าน่าจะต้องจับสัญญาณตั้งแต่ก่อนเริ่มแล้วว่านี่จะเป็นประเด็นสำคัญ
• สำหรับวันที่ใน JS ฉันใช้สตริง iso เพราะมันมีหลุมพรางอันตรายเยอะมาก (แค่ดูคำถามช่วงต้น ๆ ของควิซก็พอรู้แล้ว) ไลบรารีทางเลือกยอดนิยมอย่าง Moment ก็มีปัญหาร้ายแรงคล้ายกันในหลายด้าน มันเอาแนวคิดอย่าง "date", "time", "datetime" มาปนกันจนยิ่งสับสนกว่าเดิม ฉันยังเคยได้ยินคำอธิบายทำนองว่าไม่ควรแยก "time" กับ "date" ด้วย ซึ่งสำหรับประสบการณ์ฉันแล้วมันไม่ตรงเลย
  • ไลบรารีดัง ๆ อย่าง Moment, Luxon, Day.js มีความผิดพลาดตรงที่จัดการแนวคิดเรื่องเวลาแยกกันคนละแบบ (เช่น absolute time, civil time ฯลฯ) ด้วยออบเจ็กต์ตัวเดียว ราวกับว่าเวลาสัมบูรณ์กับเวลาเชิงปฏิทินเป็นสิ่งเดียวกัน และพยายามฝืนรวมมันเข้าด้วยกัน
• คะแนนที่ฉันได้คือ... 28 พฤศจิกายน 2000... มั้ง
  • ฉันขำกับอันนี้อยู่นานเลย
• สิ่งหนึ่งที่ฉันสงสัยคือมันกลายมาเป็นแบบนี้ได้ยังไง มันดูเหมือนผลลัพธ์จากการที่มือใหม่หลายคนมานั่งยัด heuristic ที่ไม่สม่ำเสมอและแทบเอามาผสมกันไม่ได้เข้าไปแบบเร่งรีบ แต่ในความเป็นจริงมันคงไม่ใช่งานของมือใหม่ แล้วอะไรทำให้สถานการณ์ออกมาเป็นแบบนี้กันแน่
  • มีคนพูดถึงในคอมเมนต์อื่นแล้วว่า Brendan Eich พูดเองบนทวิตเตอร์ (ลิงก์) ว่ามันแค่คัดลอกพฤติกรรมของคลาส Date ใน Java มา สำหรับฉันบริบททางประวัติศาสตร์แบบนี้น่าสนใจดี
  • โดยพื้นฐานแล้วปัญหาส่วนใหญ่เกิดจากการฝืนพาร์สสตริงประหลาด ๆ ที่จริง ๆ แล้วไม่ได้เกี่ยวอะไรกับวันที่เลย แทบทั้งหมดเป็น edge case แน่นอนว่าใน edge case แบบนี้ถ้าจะให้ดีก็ควร error อย่างสม่ำเสมอมากกว่า แต่ถ้าคุณไม่ได้เอาสตริงอะไรก็ได้ที่ผู้ใช้พิมพ์มาโยนเข้า Date.parse() ตรง ๆ มันก็ไม่ได้เป็นปัญหาใหญ่ขนาดนั้น ในทางปฏิบัติก็มักใช้ไลบรารีวันที่เฉพาะทางอยู่แล้ว เพราะแม้แต่ส่วนที่พอใช้ได้ของ Date เองก็ไม่ได้ยอดเยี่ยมอะไรนัก
  • ถ้าภาษาอนุญาตให้ทำ operator overriding ได้ หรือไม่มี static type ก็มักจะเกิดกรณีที่เมธอดเดียวต้องรองรับการใช้งานต่างกัน 10 แบบ Java หรือ C++ เองก็มี API ที่ไม่สม่ำเสมอแบบนี้เยอะเหมือนกัน (แค่ไม่หนักเท่า JS)
• ควิซ JS เป็นอะไรที่กดเข้าไปดูเพื่อขำได้เสมอ ฉันใช้ JS มาเกิน 10 ปีแล้ว แต่ไม่เคยพาร์สสตริงเป็น Date ถ้ายังไม่ตรวจด้วย regex ก่อน
  • งั้นคุณก็สร้างปัญหาขึ้นมาสองชั้นเลย
  • รู้สึกร่วมคล้าย ๆ กัน ฉันเขียนโค้ด JS ด้านความปลอดภัยมา 10 ปี ช่วงนั้นเป็นตอนที่มาตรฐานมีการอัปเดตใหญ่ ระบบของเราใช้แค่ส่วนเล็กมาก ๆ ที่ทำงานได้สม่ำเสมอและคาดเดาได้ข้ามเบราว์เซอร์ หลังมาตรฐานเปลี่ยน เราเพิ่มแค่ array.filter กับ structuredcopy แล้วที่เหลือก็เมินหมด เพราะแทบไม่มีประโยชน์จริงและมีแต่เพิ่มพื้นผิวการโจมตี แล้ว TypeScript ก็ออกมา ซึ่งฉันคิดว่าเป็นโอกาสที่สูญเปล่าครั้งใหญ่ที่สุดในประวัติศาสตร์ของ JS จนถึงตอนนี้ การเขียนโค้ด JS ให้ถูกต้องจริง ๆ ก็คือการใช้ภาษานี้อย่างระมัดระวังเพียง 1% เท่านั้น และแม้กระทั่งส่วนนั้นก็ยังต้องใช้อย่างรอบคอบ