new Date("wtf") - Seberapa paham Anda tentang kelas Date di JavaScript?

• Kuis ini berfokus pada bagaimana kelas Date di JavaScript berperilaku dalam berbagai situasi input
• Mencakup eksperimen tentang hasil yang dikembalikan oleh kelas Date, apakah terjadi pengecualian, cara pemrosesan internal, dan lain-lain saat menerima nilai input yang tidak terduga oleh pengguna (misalnya "wtf" dan sebagainya)
• Melalui kuis ini, Anda dapat dengan mudah memahami momen-momen pengecualian pada JavaScript Date, strategi parsing, ketidakpatuhan terhadap standar, serta pola perilaku tak terduga lainnya
• Ditujukan untuk meningkatkan pemahaman pengembang JavaScript dan penanggung jawab pengujian agar dapat mengurangi kesalahan pemrosesan tanggal dan ketidakpastian yang mungkin terjadi dalam program nyata

[GN⁺]

Komentar Hacker News

• Di konsol JS firefox saya, jawabannya keluar berbeda dari kuis ini
• Saya harap orang-orang tidak terus mengejek JavaScript. Dulu orang juga begitu, lalu Node muncul dan sekarang sudah menyebar ke seluruh dunia
  • Menurut saya TypeScript mungkin adalah pilihan terbaik di antara bahasa yang bisa dipakai dengan dibayar
  • Ini mengingatkan saya pada meme WAT yang selama hampir 10 tahun diperlakukan orang seolah-olah undefined behaviour adalah bukti pamungkas bahwa teknologi itu tidak bermakna. Padahal sebenarnya orang cuma salah paham terhadap konsep teknologi itu sendiri. Tidak lucu kalau batu bata tidak bisa dipakai menampung air, tapi entah kenapa semua orang berharap JavaScript akan menangkap semua ~kesalahan~ sebagai error atau memperbaikinya sendiri. Itu tujuan yang bagus, tapi kalau itu tidak mungkin lalu malah dibanggakan juga terasa sudut pandang yang aneh. Saya merasa suasana seperti ini berlangsung terlalu lama
• Menurut saya ini kuis yang seru. Banyak perilaku yang cukup mengejutkan. Tapi dalam praktiknya rasanya kebanyakan tidak terlalu penting. Di situasi nyata, sebaiknya pikirkan dulu apakah Anda benar-benar butuh waktu lokal, dan apakah lebih tepat memakai satuan instant. Kalau memakai string UTC ISO 8601 atau Unix timestamp, sebagian besar kompleksitas hilang, atau setidaknya hanya perlu ditangani di sebagian kecil perangkat lunak. Tentu tidak selalu begitu (pernah ada kasus waktu istirahat pengguna harus mencakup dua rentang 1–5, dan itu benar-benar menyiksa di batas DST). Meski begitu, dari pengalaman saya, dalam kebanyakan kasus tetap mungkin mencari cara untuk meminimalkan area yang harus dipikirkan. Kalau input pengguna yang sama sekali belum divalidasi langsung dilempar ke date parser, itu berarti cara pakainya yang salah
  • Karena cara mengubah input pengguna ke format yang benar memang parsing, menurut saya masuk akal untuk menyerahkannya ke date parser yang disediakan bahasa. Fakta bahwa ini tidak berjalan baik rasanya tidak terlalu mengejutkan bagi programmer JavaScript
  • Saya sepenuhnya setuju dengan pernyataan "jangan mengirim input pengguna yang belum divalidasi ke date parser". Tapi perbedaan antara API yang baik dan yang buruk adalah, API yang baik akan langsung gagal saat ada yang aneh dan memberi tahu "kamu memakainya dengan salah". Begitu ada sesuatu yang sedikit saja janggal, seharusnya langsung gagal dengan benar, bukan berusaha mati-matian memproses data aneh. Menurut saya masalahnya adalah banyak API JS dirancang untuk tetap berjalan apa pun yang terjadi. Saya tidak mau hasilnya NaN, dan juga tidak mau konversi string yang serba tanggung
  • Setiap kali saya mendengar orang bilang "pakai saja string UTC ISO 8601 atau Unix timestamp", saya merasa mereka hanya pernah menangani tanggal dengan cara yang sangat terbatas. Coba pikirkan strategi itu untuk tanggal di masa depan. Misalnya janji "ketemu jam 7 malam" tetap pentingnya adalah bertemu jam 7, meskipun daylight saving time berubah atau waktu bergeser. Hal seperti ini sebenarnya sering terjadi. Sebenarnya masalahnya lebih halus dari itu. Di beberapa aplikasi, konteks zona waktu memang wajib ada. Misalnya layanan yang menampilkan reservasi restoran harus menampilkan berdasarkan waktu lokal restoran, bukan waktu lokal pengguna. Yang penting adalah waktu di "sana", bukan saya sedang berada di mana sekarang. Jadi GMT/UTC bukan obat mujarab untuk semua masalah tanggal. Untuk tanggal masa lalu itu memang solusi yang lumayan baik, tapi bahkan dalam kasus begitu pun sering membantu kalau waktu lokal pengguna atau zona waktu saat kejadian juga disimpan terpisah
  • Saya juga merasa memberi opsi untuk menentukan offset DST secara eksplisit adalah pendekatan yang bagus. Dalam beberapa situasi itu berguna. Saya juga selalu bingung kenapa Excel saat memakai CSV tidak berhenti menebak format sendiri
  • Saya setuju dengan ini. Ini jebakan yang mudah menelan pemula, jadi saya harap kuis ini membuat banyak orang berpikir ulang sekali lagi
• Ada sangat banyak bagian yang mengejutkan! Kesan umumnya, parser berusaha terlalu keras untuk menafsirkan input yang diberikan menjadi tanggal bagaimanapun caranya. Meski tafsirannya sangat tidak berprinsip, atau bahkan cukup aneh sampai pengguna manusia pun tidak akan setuju, rasanya tetap dipaksa diberi makna. Bahkan saat sebenarnya tidak bisa ditafsirkan pun ada cara untuk memberi sinyal error, tapi rasanya itu tidak dimanfaatkan secara aktif. Tentu bisa jadi sebagian kasus aneh ini berasal dari use case dunia nyata yang memang aneh juga
  • Perilaku seperti ini rasanya bahkan tidak bisa diprediksi. Ini nyaris cuma noise acak. String 32–49 ditafsirkan sebagai tahun 2000-an, sementara 50 ke atas justru dibaca sebagai 1900-an. Dalam situasi seperti ini, menurut saya memang sebaiknya dirombak total lalu dibuat ulang saja
  • Saya paham dorongan untuk menulis kode yang selalu berusaha menghasilkan hasil valid apa pun yang terjadi. Tapi kebanyakan orang bisa menahan dorongan itu. Jadi saya penasaran kenapa orang yang merancang ini tidak bisa menahannya
  • Fenomena ini adalah masalah yang umum pada developer dengan pengalaman beberapa tahun. Developer junior sibuk melihat error dan sekadar membuatnya jalan. Developer level menengah terobsesi dengan mentalitas "pokoknya kurangi error" sehingga parser membuat asumsi berlebihan. Dari situlah lahir fenomena seperti kelas Date. Developer senior sangat memahami bahaya error seperti ini, lalu merancang secara konsisten dan robust sehingga input yang salah langsung menghasilkan error
• Saya dapat 17/28. Benar-benar... soal-soal terkutuk! Mungkin sekarang memang waktunya saya mulai melirik stuff Temporal ini juga
  • Kelihatannya memang lama sekali sampai benar-benar rilis. Kalau baca update terbarunya malah agak lucu: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes
• Saya dapat 10/28. Tidak terlalu buruk, tapi menurut saya hasilnya bisa berbeda tergantung implementasi: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
  • Saya dapat 17/28 dan tidak tahu harus bangga atau malu. Saya sendiri juga heran kenapa saya tahu hal-hal seperti ini. Anak saya sama sekali tidak punya pengalaman dengan JS Date, tapi cuma menebak dari jawaban sebelumnya dan dapat 11/28. Saya yang menjelaskan apa itu type coercion kepadanya. Jadinya saya sempat berpikir jangan-jangan saya malah menghalangi anak saya masuk jalur karier IT
  • Memang benar-benar berbeda tergantung implementasi. Saya sengaja menulis di bagian paling awal kuis bahwa hasilnya diverifikasi pada versi Node tertentu dan zona waktu tertentu, karena keduanya sangat memengaruhi hasil
  • Saya melihat di awal kuis penulis memang mencantumkan zona waktu persis dari laptopnya. Sepertinya salah satu soal yang saya jawab salah ya karena saya tidak memperhatikan itu. Menurut saya itu penjelasan yang valid. Rasanya saya seharusnya sadar sejak awal bahwa hal seperti itu akan menjadi kunci
• Di JS, saya memakai string iso untuk tanggal karena jebakan berbahayanya terlalu banyak. (Bahkan dari beberapa soal awal kuis pun sudah kelihatan) Library alternatif populer seperti Moment dan sebagainya juga sama-sama bermasalah dalam banyak hal. Mereka mencampuradukkan konsep "date", "time", dan "datetime" sehingga membuat kebingungan lebih besar. Saya juga pernah mendengar penjelasan seolah pemisahan "time" dan "date" itu tidak perlu, tapi itu sama sekali tidak cocok dengan pengalaman saya
  • Library terkenal seperti Moment, Luxon, dan Day.js melakukan kesalahan dengan menangani konsep waktu yang berbeda (waktu absolut, waktu sipil, dll.) dalam satu objek. Seolah-olah waktu absolut dan waktu sipil itu ya sama saja. Terlalu dipaksakan jadi satu
• Skor yang saya dapat adalah... 28 November 2000... sepertinya
  • Saya tertawa lama melihat ini
• Satu hal yang saya penasaran adalah bagaimana ini bisa terjadi. Hasilnya terlihat seperti kumpulan heuristik yang saling tidak konsisten, dibuat terburu-buru oleh para pemula, dan bahkan tidak bisa dicampur satu sama lain. Tapi kenyataannya pasti bukan karya para pemula, jadi saya penasaran situasi apa yang bisa menghasilkan keadaan seperti ini
  • Sudah disebut di komentar lain juga, Brendan Eich sendiri menyebut di Twitter (tautan) bahwa perilaku kelas Date di Java tinggal disalin begitu saja. Bagi saya konteks sejarah seperti ini menarik
  • Pada dasarnya sebagian besar masalah muncul saat memaksa parsing string aneh yang sebenarnya sama sekali tidak berhubungan dengan tanggal. Hampir semuanya edge case. Tentu akan lebih baik kalau di edge case seperti itu dia lebih konsisten dan langsung error saja, tapi selama Anda tidak memasukkan sembarang string input pengguna langsung ke Date.parse(), ini tidak terlalu jadi masalah. Dalam praktiknya Anda akan memakai library tanggal khusus juga. Bahkan bagian Date yang lumayan pun sebenarnya tidak terlalu bagus
  • Kalau suatu bahasa memungkinkan operator overriding atau tidak punya static typing, kadang satu method harus berperilaku sesuai 10 kegunaan berbeda. Java dan C++ juga punya cukup banyak API yang tidak konsisten seperti ini (meski memang tidak separah JS)
• Kuis JS memang menyenangkan untuk diklik sekadar buat tertawa. Saya sudah pakai JS lebih dari 10 tahun, dan belum pernah parsing string ke Date tanpa memvalidasinya dulu dengan regex
  • Kalau begitu, Anda malah membuat dua masalah
  • Saya juga merasa mirip. Selama 10 tahun saya menulis kode JS terkait keamanan. Itu terjadi saat standar sedang mendapat pembaruan besar. Sistem kami hanya memakai bagian yang sangat kecil, yang benar-benar konsisten dan bisa diprediksi di semua browser. Bahkan setelah standar berubah, kami cuma menambahkan array.filter dan structuredcopy, lalu mengabaikan sisanya karena nyaris tidak ada manfaat praktis dan cuma menambah attack surface. Lalu TypeScript muncul, dan menurut saya itu adalah peluang terbesar yang disia-siakan dalam sejarah JS. Sampai sekarang pun, coding yang benar di JS pada dasarnya berarti memakai hanya 1% dari bahasanya dengan sangat hati-hati. Itu pun masih harus dipakai dengan penuh kehati-hatian