Satu bug penapisan tarikh yang kelihatan mudah dalam JavaScript telah mencetuskan perbincangan meluas dalam kalangan pembangun mengenai perangkap terkenal dalam bekerja dengan tarikh dan masa dalam aplikasi web. Isu ini berlaku apabila sistem dashboard secara misteri mengecualikan semua data yang dicipta sebelum 9 pagi waktu tempatan, mendedahkan salah faham asas tentang cara JavaScript mengendalikan rentetan tarikh.
Punca Utama: Kekeliruan UTC vs Waktu Tempatan
Masalah ini berpunca daripada constructor new Date('YYYY-MM-DD') JavaScript , yang mencipta tarikh pada tengah malam UTC dan bukannya waktu tempatan. Bagi pengguna di Japan (UTC+9), ini bermakna apa yang kelihatan sebagai 1 Januari pada tengah malam sebenarnya adalah 9 pagi waktu tempatan. Sebarang rekod yang dicipta antara tengah malam dan 8:59:59 pagi telah ditapis keluar secara tidak sengaja daripada hasil dashboard.
Tingkah laku ini berlaku kerana JavaScript mentafsir rentetan tarikh sahaja sebagai waktu UTC, manakala rentetan tarikh-masa dianggap sebagai waktu tempatan. Ketidakkonsistenan ini telah mengejutkan banyak pembangun dan terus menjadi sumber bug dalam sistem pengeluaran di seluruh dunia.
Tingkah Laku Konstruktor Tarikh JavaScript:
new Date('YYYY-MM-DD')→ Mencipta tarikh pada tengah malam UTCnew Date('YYYY-MM-DDTHH:MM:SS')→ Mencipta tarikh dalam masa tempatan- Untuk Japan (UTC+9): '2000-01-01' menjadi 2000-01-01T09:00:00+09:00
Komuniti Menyeru Amalan Pengendalian Tarikh yang Lebih Baik
Insiden ini telah mencetuskan semula perbincangan mengenai API Date JavaScript yang bermasalah. Ramai pembangun menyokong penggunaan perpustakaan khusus atau cadangan Temporal yang akan datang, yang bertujuan menyediakan pendekatan yang lebih intuitif dan kurang terdedah kepada ralat untuk pengendalian tarikh.
Simpan semua logik perniagaan dalam UTC, dan tukar dari/ke waktu tempatan sedekat mungkin dengan UI
Beberapa ahli komuniti menekankan kepentingan menyimpan tarikh sebagai timestamp Unix dan melakukan semua pengiraan dalam UTC. Pendekatan ini meminimumkan kekeliruan berkaitan zon waktu dan memastikan tingkah laku yang konsisten merentasi lokasi geografi yang berbeza.
Penyelesaian Alternatif:
- Perpustakaan manipulasi tarikh ( date-fns )
- Cadangan API Temporal (standard JavaScript masa depan)
- Sentiasa simpan tarikh sebagai nombor epoch Unix
- Elakkan andaian zon masa sebelah pelanggan
Memandang ke Hadapan: Piawaian dan Amalan yang Lebih Baik
Perbincangan ini menyerlahkan keperluan yang lebih luas untuk pengendalian tarikh yang diperbaiki dalam aplikasi JavaScript . Walaupun pembetulan semasa melibatkan penentuan zon waktu tempatan secara eksplisit dalam rentetan tarikh, pembangun semakin mencari penyelesaian yang lebih kukuh seperti cadangan API Temporal , yang menjanjikan untuk menangani banyak kekurangan objek Date semasa.
Insiden ini berfungsi sebagai peringatan bahawa walaupun operasi yang kelihatan mudah seperti penapisan tarikh boleh menyembunyikan tingkah laku zon waktu yang kompleks yang mempengaruhi pengguna sebenar dan operasi perniagaan.