บั๊กใน JavaScript Date Constructor ทำให้แดชบอร์ดพลาดข้อมูลช่วงเช้าในญี่ปุ่น

บั๊กการกรองวันที่ที่ดูเหมือนง่ายๆ ใน JavaScript ได้จุดประกายการอพยพอย่างกว้างขวางในหมู่นักพัฒนาเกี่ยวกับข้อผิดพลาดที่น่าหวาดเสียวของการทำงานกับวันที่และเวลาในเว็บแอปพลิเคชัน ปัญหานี้เกิดขึ้นเมื่อระบบแดชบอร์ดตัดข้อมูลทั้งหมดที่สร้างขึ้นก่อน 9 โมงเช้าตามเวลาท้องถิ่นอย่างลึกลับ ซึ่งเผยให้เห็นความเข้าใจผิดพื้นฐานเกี่ยวกับวิธีที่ JavaScript จัดการกับสตริงวันที่

สาเหตุหลัก: ความสับสนระหว่าง UTC กับเวลาท้องถิ่น

ปัญหาเกิดจาก constructor new Date('YYYY-MM-DD') ของ JavaScript ที่สร้างวันที่ตรงเที่ยงคืน UTC แทนที่จะเป็นเวลาท้องถิ่น สำหรับผู้ใช้ในญี่ปุ่น (UTC+9) นี่หมายความว่าสิ่งที่ดูเหมือนจะเป็นวันที่ 1 มกราคมตรงเที่ยงคืนนั้นจริงๆ แล้วคือ 9 โมงเช้าตามเวลาท้องถิ่น บันทึกใดๆ ที่สร้างขึ้นระหว่างเที่ยงคืนถึง 8:59:59 น. ถูกกรองออกจากผลลัพธ์ของแดชบอร์ดโดยไม่ได้ตั้งใจ

พฤติกรรมนี้เกิดขึ้นเพราะ JavaScript ตีความสตริงที่มีเฉพาะวันที่เป็นเวลา UTC ในขณะที่สตริงวันที่-เวลาถูกปฏิบัติเป็นเวลาท้องถิ่น ความไม่สอดคล้องนี้ทำให้นักพัฒนานับไม่ถ้วนประหลาดใจและยังคงเป็นแหล่งของบั๊กในระบบที่ใช้งานจริงทั่วโลก

พฤติกรรมของ JavaScript Date Constructor:

• new Date('YYYY-MM-DD') → สร้างวันที่เวลาเที่ยงคืนตาม UTC
• new Date('YYYY-MM-DDTHH:MM:SS') → สร้างวันที่ตามเวลาท้องถิ่น
• สำหรับ Japan (UTC+9): '2000-01-01' จะกลายเป็น 2000-01-01T09:00:00+09:00

ชุมชนเรียกร้องแนวทางการจัดการวันที่ที่ดีกว่า

เหตุการณ์นี้ได้จุดประกายการอพยพเกี่ยวกับ Date API ที่มีปัญหาของ JavaScript ขึ้นมาใหม่ นักพัฒนาหลายคนกำลังสนับสนุนการใช้ไลบรารีเฉพาะทางหรือข้อเสนอ Temporal ที่กำลังจะมาถึง ซึ่งมุ่งหมายที่จะให้แนวทางการจัดการวันที่ที่ใช้งานง่ายและมีข้อผิดพลาดน้อยกว่า

เก็บตรรกะทางธุรกิจทั้งหมดใน UTC และแปลงจาก/ไปเป็นเวลาท้องถิ่นให้ใกล้กับ UI ที่สุดเท่าที่จะเป็นไปได้

สมาชิกชุมชนหลายคนเน้นย้ำถึงความสำคัญของการจัดเก็บวันที่เป็น Unix timestamps และการคำนวณทั้งหมดใน UTC แนวทางนี้ช่วยลดความสับสนที่เกี่ยวข้องกับเขตเวลาและรับประกันพฤติกรรมที่สอดคล้องกันในสถานที่ทางภูมิศาสตร์ที่แตกต่างกัน

ทางเลือกอื่น:

• ไลบรารีสำหรับจัดการวันที่ ( date-fns )
• ข้อเสนอ Temporal API (มาตรฐาน JavaScript ในอนาคต)
• เก็บวันที่เป็นตัวเลข Unix epoch เสมอ
• หลีกเลี่ยงการสันนิษฐานเขตเวลาฝั่งไคลเอนต์

มองไปข้างหน้า: มาตรฐานและแนวทางปฏิบัติที่ดีกว่า

การอภิปรายนี้เน้นย้ำถึงความจำเป็นในวงกว้างสำหรับการจัดการวันที่ที่ดีขึ้นในแอปพลิเคชัน JavaScript ในขณะที่การแก้ไขปัจจุบันเกี่ยวข้องกับการระบุเขตเวลาท้องถิ่นในสตริงวันที่อย่างชัดเจน นักพัฒนากำลังมองหาโซลูชันที่แข็งแกร่งกว่ามากขึ้นเช่นข้อเสนอ Temporal API ซึ่งสัญญาว่าจะแก้ไขข้อบกพร่องหลายอย่างของออบเจ็กต์ Date ปัจจุบัน

เหตุการณ์นี้เป็นการเตือนใจว่าแม้แต่การดำเนินการที่ดูเหมือนตรงไปตรงมาเช่นการกรองวันที่ก็สามารถซ่อนพฤติกรรมเขตเวลาที่ซับซ้อนที่ส่งผลต่อผู้ใช้จริงและการดำเนินงานทางธุรกิจ

อ้างอิง: When JavaScript Decided My Day Starts at 9AM