new Date("wtf") - JavaScript'in Date sınıfını ne kadar iyi biliyorsunuz?

• Bu quiz, JavaScript'in Date sınıfının çeşitli girdi durumlarında nasıl davrandığına odaklanıyor
• Kullanıcının beklemediği girdi değerleri (ör. "wtf" vb.) geldiğinde Date sınıfının döndürdüğü sonuçlar, istisna üretip üretmediği, iç işleme biçimi gibi deneyler içeriyor
• Bu quiz sayesinde JavaScript Date'in istisnai anlarını, ayrıştırma stratejilerini, standarda uyumsuzluklarını ve beklenmedik davranış kalıplarını kolayca kavrayabilirsiniz
• JavaScript geliştiricileri ve test sorumluları için, gerçek programlarda ortaya çıkabilecek tarih işleme hataları ve belirsizlikleri azaltmaya yönelik anlayışı artırmayı amaçlıyor

[GN⁺]

Hacker News yorumu

• Benim Firefox JS konsolumda bu testtekinden farklı cevaplar çıkıyor
• JavaScript’le dalga geçilmemesini isterdim. Eskiden insanlar bunu yapıyordu, sonra Node çıktı ve şimdi her yere yayılmış durumda
  • TypeScript’in muhtemelen para karşılığı kullanılabilen diller arasında en iyi seçenek olduğunu düşünüyorum
  • İnsanların neredeyse 10 yıl boyunca undefined behaviour'ı teknolojinin anlamsızlığına dair kesin kanıt gibi gördüğü WAT memi aklıma geldi. Aslında mesele sadece insanların teknoloji kavramını yanlış anlamasıydı. Tuğlayla su taşınamaması komik bir şey değil ama nedense herkes JavaScript’in tüm ~hataları~ ya hata olarak yakalamasını ya da kendi kendine düzeltmesini bekliyordu. Güzel bir hedef ama bu mümkün değilse bununla gurur duymak gerektiğini düşünmek de tuhaf bir bakış açısıydı. Bu atmosfer çok uzun sürdü
• Bence eğlenceli bir test. Şaşırtıcı davranışlar çok fazla. Ama gerçekte çoğu zaman pek önemli olmadığını düşünüyorum. Gerçek bir durumda gerçekten yerel saate ihtiyacınız olup olmadığını ve önce instant düzeyinde kullanmanın uygun olup olmadığını düşünmek iyi olur. UTC ISO 8601 dizeleri ya da Unix timestamp kullanırsanız karmaşıklığın büyük kısmı ortadan kalkar ya da en azından yazılımın sadece bir bölümünde ele alınır. Tabii her zaman böyle değil (bir keresinde kullanıcının mola saatinin 1-5 arası iki aralığı kapsaması gerekiyordu ve DST sınırında gerçekten işkenceydi). Yine de çoğu durumda ilgilenilecek alanı en aza indirmenin bir yolunu bulmanın mümkün olduğunu deneyimledim. Hiç doğrulanmamış kullanıcı girdisini doğrudan date parser’a veriyorsanız, kullanım şekli yanlıştır
  • Kullanıcı girdisini doğru biçime dönüştürmenin adı zaten parsing olduğu için, dilin sağladığı date parser’a vermenin mantıklı olduğunu düşünüyorum. Bunun iyi çalışmaması JavaScript programcıları için pek şaşırtıcı değil
  • “Hiç doğrulanmamış kullanıcı girdisini date parser’a vermemek gerekir” sözüne tamamen katılıyorum. Ama iyi bir API ile kötü bir API arasındaki fark şu: iyi bir API bir tuhaflık varsa hemen başarısız olur ve “bunu yanlış kullanıyorsun” der. Bir şey azıcık bile anormalse düzgün şekilde başarısız olmalı, garip veriyi bir şekilde işlemeye çalışmamalı. Bence birçok JS API’sinin sorunu, ne olursa olsun çalışacak şekilde tasarlanmış olmaları. Ne NaN çıkmasını isterim ne de dizelerin yarım yamalak dönüştürülmesini
  • Her “sadece UTC ISO 8601 dizeleri ya da Unix timestamp kullanın” dendiğinde, bunu söyleyenlerin tarihleri çok sınırlı bir şekilde ele aldığı hissine kapılıyorum. Bunu gelecekteki tarihlere uygulamayı düşünün. Mesela “akşam 7’de buluşalım” gibi bir plan için yaz saati uygulaması ya da saat değişse de önemli olan 7’de buluşmaktır. Bu tür şeyler gerçekte sık olur. Aslında mesele daha da ince. Bazı uygulamalarda mutlaka zaman dilimi bağlamı gerekir. Örneğin restoran rezervasyonlarını gösteren bir hizmette, kullanıcının yerel saati değil restoranın yerel saat dilimi gösterilmelidir. Rezervasyon saati için önemli olan “oranın” saati, benim şu anda nerede olduğum değil. Yani GMT/UTC tüm tarih problemlerinin her derde devası değil. Geçmiş tarihler için iyi bir çözüm olabilir ama o durumda bile kullanıcının yerel saatini ya da etkinlik anındaki zaman dilimini ayrıca saklamak çoğu zaman faydalı olur
  • DST offset’ini açıkça belirtebilme seçeneği vermenin de iyi bir yöntem olduğunu düşünüyorum. Duruma göre faydalı olabilir. Excel’in CSV kullanırken biçimi kendisinin tahmin etmemesi bana hep kafa karıştırıcı gelmiştir
  • Buna katılıyorum. Yeni başlayanların kolayca düşebileceği bir tuzak ve umarım bu test birçok kişinin bir kez daha düşünmesine vesile olur
• Şaşırtıcı kısım gerçekten çok fazla! Genel tablo bana parser’ın verilen girdiyi ne pahasına olursa olsun bir tarih olarak yorumlamaya aşırı uğraştığını gösteriyor. Bu yorumlama çok ilkesiz olsa, hatta insan kullanıcı baksın yine de katılmayacağı kadar tuhaf olsa bile zorla bir anlam yüklüyor gibi. Gerçekte yorumlayamadığı durumlarda bile hata sinyali verebilecekken bunu aktif biçimde kullanmıyor hissi var. Tabii belki de bu tuhaf örnekler gerçek dünyadaki garip kullanım senaryolarından geliyordur
  • Bu tür davranışların öngörülmesi bile mümkün değil gibi geliyor. Neredeyse rastgele gürültü. 32-49 arası dizeler 2000’ler olarak çıkarken, 50’den sonrası 1900’ler olarak yorumlanıyor. Böyle durumlarda her şeyi yıkıp baştan yapmak gerekir diye düşünüyorum
  • Her koşulda geçerli bir sonuç üretmeye çalışma dürtüsünü anlıyorum. Ama çoğumuz bu dürtüyü bastırabiliyorduk. Bunu tasarlayanlar neden bastıramadı merak ediyorum
  • Bu olgu birkaç yıllık deneyimi olan geliştiricilerde sık görülen bir sorun. Junior geliştirici sadece hataları görür ve bir şekilde çalıştırmaya uğraşır. Mid-level geliştirici “ne pahasına olursa olsun hata sayısını azaltalım” zihniyetine takılır ve parser aşırı fazla varsayım yapar. Sonuçta Date sınıfındaki gibi şeyler ortaya çıkar. Senior geliştirici ise böyle hataların riskini çok iyi bilir, tutarlı ve robust tasarlar, yanlış girdi gelince hemen hata üretir
• 17/28 aldım. Gerçekten... lanetli sorular olduklarını düşünüyorum! Sanırım artık bu Temporal stuff’a da bir göz atmanın zamanı geldi
  • Bunun çıkması gerçekten çok uzun sürüyor gibi. Son güncellemeyi okuyunca biraz komik geliyor: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes
• 10/28 yaptım. Fena değil ama sonuçların implementasyona göre değişebileceğini düşünüyorum: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings
  • Ben 17/28 aldım ama gurur mu duymalıyım yoksa utanmalı mıyım bilmiyorum. Neden böyle şeyleri bildiğimi ben de merak ediyorum. Oğlumun JS Date ile hiç deneyimi yoktu ama önceki cevaplara bakıp çıkarım yaparak 11/28 aldı. Type coercion’ın ne olduğunu ben anlattım. Sonra da acaba oğlumun IT kariyerine engel mi oldum diye düşündüm
  • Gerçekten implementasyona göre değişiyor. Testin en başına özellikle belirli bir Node sürümünde ve belirli bir saat diliminde doğrulandığını yazmıştım; ikisi de sonuç üzerinde önemli etkiye sahip
  • Testin başında yazarın kendi dizüstü bilgisayarının tam zaman dilimini belirttiğini görmüştüm. Kaçırdığım sorulardan biri sanırım buna dikkat etmediğim içindi. Bence gayet makul bir açıklama. Başlamadan bunun kilit nokta olacağını fark etmem gerekirdi
• JS’te tarihleri ISO dizeleriyle kullanıyorum çünkü tehlikeli tuzaklar çok fazla. (Bunu testin ilk birkaç sorusunda bile görebilirsiniz.) Moment gibi popüler alternatif kütüphaneler de birçok açıdan aynı derecede sorunlu. date, time, datetime kavramlarını birbirine karıştırıp daha büyük bir kafa karışıklığı yaratıyorlar. “time” ve “date” diye bir ayrım olmaması gerektiği yönünde açıklamalar da duydum ama bu benim deneyimimle hiç örtüşmüyor
  • Moment, Luxon, Day.js gibi bilinen kütüphaneler ayrı zaman kavramlarını (mutlak zaman, sivil zaman vb.) tek bir nesnede ele alma hatasına düşüyor. Mutlak zamanla sivil zaman gerçekten aynı şey mi? Zorla tek bir şeye indirgeniyorlar
• Benim aldığım puan... sanırım 28 Kasım 2000...
  • Buna bayağı güldüm
• Merak ettiğim şeylerden biri, bunun nasıl olduğu. Ortada gerçekten acemilerin aceleyle yaptığı, tutarsız ve birbiriyle bile birleştirilemeyen türlü türlü heuristics’in dolaştığı bir sonuç var gibi görünüyor. Ama gerçekte bunu acemiler yapmamış olmalıydı; bu hale neyin getirdiğini merak ediyorum
  • Başka yorumlarda da değinilmişti; Brendan Eich Twitter’da (bağlantı) doğrudan bunun Java’nın Date sınıfı davranışının kopyası olduğunu söyledi. Bu tarihsel bağlam bana ilginç geliyor
  • Esasen sorunların çoğu, tarihle hiç ilgisi olmayan garip dizeleri zorla parse etmeye çalışmaktan kaynaklanıyor. Neredeyse tamamen edge case. Tabii edge case’lerde daha tutarlı biçimde sadece hata vermesi daha iyi olurdu ama kullanıcıdan gelen rastgele bir diziyi doğrudan Date.parse() içine atmıyorsanız o kadar da büyük bir sorun değil. Pratikte zaten uzmanlaşmış tarih kütüphaneleri kullanılıyor. Date’in iyi sayılan tarafları bile o kadar iyi değil çünkü
  • Bir dilde operator overriding mümkünse ya da statik tip yoksa, tek bir metodun birbirinden tamamen farklı 10 kullanım için çalışması gerektiği durumlar sık görülür. Java ya da C++’ta da böyle tutarsız API’ler var (yine de JS kadar kötü değil)
• JS testlerine gülmek için tıklamanın ayrı bir keyfi var. 10 yıldan uzun süredir JS kullanıyorum ama regex ile doğrulanmamış bir diziyi Date olarak parse etmiş değilim
  • O zaman iki problem birden yaratmış oluyorsun
  • Benzer bir empati. 10 yıl boyunca güvenlik odaklı JS kodu yazdım. Bu, standardın ciddi biçimde güncellendiği döneme denk geliyordu. Sistemimiz tarayıcılar arasında tutarlı ve öngörülebilir çalışan gerçekten çok küçük bir alt kümeyi kullanıyordu. Standart değiştikten sonra bile sadece array.filter ve structuredcopy ekledik; geri kalanını ise pratik faydası yok ve saldırı yüzeyini artırıyor diye tamamen görmezden geldik. Sonra TypeScript çıktı ve bunun JS tarihindeki en büyük kaçırılmış fırsat olduğunu düşünüyorum. Bugün bile JS’te düzgün kod yazmak aslında dilin %1’ini dikkatle kullanmak demek. Onu bile çok temkinli kullanmak gerekiyor