JavaScript Temporal geliyor

 (developer.mozilla.org)
2 puan yazan GN⁺ 2025-01-31 | 1 yorum | WhatsApp'ta paylaş
  • JavaScript’in yeni Temporal nesnesi tarayıcıların deneysel sürümlerine girmeye başlıyor; bu, tarih, saat, süre ve takvim işlemlerini yerleşik API ile daha doğru ve tutarlı biçimde ele almaya yönelik bir değişim
  • Mevcut Date, kullanıcının yerel zamanı ve UTC merkezli yapısı, kararsız ayrıştırma davranışı ve mutable çalışması nedeniyle saat dilimi işlemlerini ve hata ayıklamayı zorlaştırıyordu
  • Temporal, Temporal.Instant, Temporal.ZonedDateTime, Temporal.PlainDateTime, Temporal.Duration, Temporal.Now gibi yapılarla anlık zaman noktası, yerel zaman ve süreyi ayırıyor ve 200’den fazla yardımcı yöntem sunuyor
  • Kararlı, tarayıcılar arası destek için daha zamana ihtiyaç var; Firefox Nightly’de Temporal, javascript.options.experimental.temporal ayarının arkasından denenebiliyor
  • MDN’e bu hafta Temporal için 270’ten fazla sayfa dokümantasyon eklendi; @js-temporal/polyfill içeren TC39 dokümantasyon sayfasında örnekler bayrak değiştirmeden çalıştırılabiliyor

JavaScript Date’in eski sınırlamaları

  • JavaScript 1995’te oluşturulurken Date nesnesi Java’nın ilk java.util.Date uygulamasını kopyaladı; Java bunu 1997’de değiştirdi, ancak JavaScript neredeyse 30 yıl boyunca aynı API’yi korudu
  • En büyük sorunlar saat dilimi desteğinin eksikliği ve kararsız ayrıştırma davranışı
    • Yalnızca kullanıcının yerel zamanı ve UTC destekleniyor
    • Date nesnesinin kendisi mutable olduğu için takip etmesi zor hatalara yol açabiliyor
    • Daylight Saving Time (DST) ve geçmiş takvim değişikliklerini aşan hesaplamaları ele almak da zor
  • Bu kısıtlamalar nedeniyle birçok geliştirici, uygulamalarında tarih ve saat işlemleri için Moment.js veya date-fns gibi özel kütüphanelere bel bağladı

Temporal’ın değiştirdiği tarih-saat modeli

  • Temporal, Date nesnesinin tam bir alternatifi olarak tasarlandı; tarih ve saat yönetimini daha güvenilir ve öngörülebilir hâle getirmeyi hedefliyor
  • Saat dilimi ve takvim gösterimlerini destekliyor; dönüştürme, karşılaştırma, hesaplama ve biçimlendirme için yerleşik yöntemler sağlıyor
  • API yüzeyinde 200’den fazla yardımcı yöntem bulunuyor; MDN’in Temporal dokümantasyonuna açıklamalar ve örnekler eklendi

Temporal’ın başlıca tipleri

  • Temporal, benzersiz bir anı, yerel duvar saati zamanını ve süreyi farklı tiplerle ayırıyor
  • Başlıca yapılar şöyle
    • Temporal.Duration: İki zaman noktası arasındaki fark
    • Temporal.Instant: Zaman damgası olarak ifade edilen benzersiz an
    • Temporal.ZonedDateTime: Saat dilimi içeren tarih-saat
    • Temporal.PlainDateTime: Saat dilimi olmayan tam tarih-saat
      • Temporal.PlainDate: Yalnızca tarihi ifade eder
      • Temporal.PlainYearMonth: Yıl ve ay
      • Temporal.PlainMonthDay: Ay ve gün
      • Temporal.PlainTime: Yalnızca saati ifade eder
    • Temporal.Now: Geçerli zamanı çeşitli sınıf örnekleri veya belirli biçimlerde elde etmeye yarayan API

Örneklerle kullanım biçimi

  • Geçerli tarih ve saat ISO string olarak alınabiliyor; birçok yönteme saat dilimi iletilebiliyor
    • Temporal.Now.plainDateTimeISO() sistem saat dilimindeki geçerli tarih-saati döndürür
    • Temporal.Now.plainDateTimeISO("America/New_York") New York saat dilimindeki geçerli tarih-saati döndürür
  • Gregorian dışındaki takvimler de ele alınabiliyor; Hebrew, Chinese, Islamic gibi takvim sistemlerine ait tarihler oluşturulabiliyor
    • Chinese takvimindeki M01 ayının 1. günü kullanılarak bir sonraki Chinese New Year hesaplanıyor
    • Yazının yazıldığı sıradaki örnek çıktıda bir sonraki Chinese New Year 1/29/2025
  • Unix Epoch milisaniye zaman damgası Temporal.Instant.fromEpochMilliseconds() ile bir ana dönüştürülüp Temporal.Now.instant() ile karşılaştırılarak kalan süre hesaplanabiliyor
    • Örnek zaman damgası 1851222399924 için smallestUnit: "hour" ile şu andan itibaren kalan süre hesaplanıyor
    • @js-temporal/polyfill çıktısı 31,600 hr, Firefox Nightly çıktısı ise PT31600H
  • Firefox uygulamasındaki toLocaleString şu anda locale’e duyarlı string üretmiyor
    • Bu davranış teknik bir sınırlamadan çok bir tasarım kararına yakın; duration biçimlendirmesinin kendisi mümkün
    • polyfill ve Firefox uygulaması ileride birbirine yakınsayabilir
  • compare() yöntemi dizi sıralamada kullanılabiliyor
    • durations.sort(Temporal.Duration.compare) kullanıldığında PT1H, PT1H30M, PT1H45M, PT2H sırasıyla diziliyor

Tarayıcı desteği ve deneme yöntemi

İlgili okumalar

1 yorum

 
GN⁺ 2025-01-31
Hacker News yorumları

  • Temporal harika. Bir süredir polyfill ile production’da kullanıyorum; mevcut Date() API’sinde yaşadığım pek çok sorunu çözüyor
    Rust’taki chrono, Java’daki Joda Time gibi iyi zaman kütüphanelerinden ilham alıp bunları kullanımı rahat bir API’de iyi birleştirmiş gibi hissettiriyor
    Düz zaman, anlık zaman noktası ve saat dilimi içeren zamanı ayırdığı için biraz daha karmaşık; ama zamanın kendisi karmaşık olduğundan geliştiricinin bu karmaşıklıkla yüzleşmesi gerekiyor
    “Bu timestamp’e bir gün ekle” gibi bir işlemde bile bunun hangi saat dilimi temel alınarak yapılacağı mutlaka belirlenmeli; aksi halde yaz saati uygulaması, kullanıcının saat dilimini değiştirmesi veya sunucu saat dilimi farkları yüzünden bug’lar kalır
    Sabit offset’li timestamp (2025-01-01T00:00+02:00) ile belirli bir saat diliminin (Europe/Paris) serileştirme farkını da çözüyor

    • Rust crate’i Jiff de bakmaya değer. Temporal’dan ilham almış ve chrono da dahil diğer tarih-saat crate’leriyle karşılaştırmayı da derlemiş: https://docs.rs/jiff/latest/jiff/_documentation/comparison/i...
      Kişisel olarak Temporal’ın Rust’taki chronodan büyük ölçüde ilham aldığını söylemek zor; Joda veya güncel java.time ile date-fns ya da Moment.js gibi JavaScript tarih-saat kütüphanelerinin etkisi daha büyük görünüyor
    • Biraz yaşı olanlar, production ortamında yerel saatle 01:00–03:00 arasına cron işleri planlamamak gerektiğini uzun zaman önce öğrendi
    • Doğru, ama bir pürüz var. Pek çok kişi gerçek bir konumu işaret eden saat dilimi adlarını kullanmayı sevmiyor
      Europe/Parisin Fransa’nın geniş bir bölgesi mi yoksa sadece Paris mi olduğunu araştırmaya yanaşmıyor; bunu, Paris’te yaşadığını söylüyormuş gibi hissedip sinirleniyor
      Çevrimiçi topluluk etkinlikleri gibi şeyleri planlarken bu durum eziyet olmuştu. İnsanlar sabit offset kullanmak istiyor; CET/CEST gibi ifadeleri sorun etmiyor ama Europe/yourexactcoordinates gibi şeylerden hoşlanmıyor
      Aslında çoğu saat diliminin epey geniş bölgeleri kapsadığını biliyorum; ama gizliliğini önemseyip yine de “saat” ile “saat dilimi” arasındaki farkı araştırmayı düşünmeyen çok kişi var
    • chrono ve Joda Time farklı dönemlerin ürünleri. Rust 1.0 çıktığında Java bu yaklaşımı standart kütüphanedeki java.time ile zaten uygulamıştı ve bu amaç için üçüncü taraf bir kütüphaneye ihtiyaç yoktu
    • Sabit offset’li timestamp ile belirli bir saat dilimine sahip timestamp’in serileştirme farkının nasıl bir sorun olduğunu daha ayrıntılı öğrenmek isterim

  • Dokümanlarda bulmam epey zaman aldı; Temporal.ZonedDateTime.prototype.withTimeZone() bir saat diliminden diğerine dönüştürüyor: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    Temporal.ZonedDateTime.from("2021-08-01T12:00[America/New_York]") ile oluşturulan değeri withTimeZone("Europe/Paris") içine verirseniz 2021-08-01T18:00:00+02:00[Europe/Paris] olur
    Saat dilimi dönüşümü ve süre işlemleri, bir kütüphanenin mutlaka ele alması gereken temel özellikler; Temporal’ın ikisini de halletmesi güzel. Ancak Temporal.Durationda duration.format('H\hmm\m') gibi, 1h03m üreten özel bir format fonksiyonu yok gibi görünüyor

  • Şu anda TC39’da olgunlaşmakta olan epey fazla öneri var ve Temporal, bir an önce yayımlanmasını istediğim şeylerden biri
    Büyük tarayıcıların yeni özellikleri desteklemesi için v8, JSC ve SpiderMonkey mühendislerinin geliştirme emeği gerektiğini bildiğimden, ilerleme sağlayan insanlara gerçekten minnettarım
    Sabırsız biri olarak “Records ve Tuples’ı da hemen yapın! Pipe sözdizimi savaşını atlayabilirsiniz!” diye destekleyesi geliyor insanın

    • Records ve Tuples’ın yayımlanma olasılığı düşük ya da en azından insanların istediği eşitlik semantiğiyle yayımlanma olasılığı çok düşük görünüyor
      Tarayıcı sağlayıcılarının bu noktada yeni ilkel tipler eklenmesine zaten oldukça güçlü biçimde karşı çıktığını anlıyorum. Eşitliğin nasıl çalışması gerektiğine dair zorluklar şu başlıkta açıklanıyor: https://github.com/tc39/proposal-record-tuple/issues/387
      BigInt’in başta bu kadar çok kullanılacağını beklemiyordum ama pratikte yapısal eşitliğe sahip koleksiyonlara ihtiyaç duyulan durumlar sürekli ortaya çıkıyor; bu yüzden olmaması üzücü
      Yeni ilkel tip eklenmesine yönelik itirazın pattern matching’i de etkilediğini biliyorum, ama nedenini pek bilmiyorum ve o öneriyi daha az takip ediyorum
    • Temporal’ın gelmesi güzel ve başka iyi özellikler de çok olacaktır, ancak bahsedilen belirli öneriler konusunda iyimser olmak zor
      Pipeline, pattern matching ve Records+Tuples’ın hepsi 4 yılı aşkın süredir üzerinde çalışılan şeyler ve hâlâ 1–2. aşamalarda kalmış durumdalar. Son bir yılda anlamlı ilerleme, pattern matching dışında neredeyse yok gibi görünüyor
      Records ve Tuples deposundaki issue’lara göre değer semantiğine, yani ===’in çalışıp çalışamayacağına yönelik itirazlar olmuş. Değer semantiği çıkarılırsa önerinin kullanışlılığı büyük ölçüde azalır
      Bunların 3. aşamaya ulaşması en az 1–2 yıl daha sürebilir ya da hiç ulaşamayabilirler. Yine de dizi gruplama fonksiyonu geldi
    • İstediğim şey pattern matching: https://tc39.es/proposal-pattern-matching/
      Hâlâ 1. aşamada olduğu için ne yazık ki birkaç yıl daha sürecek gibi
    • Records denince, Dictionary’nin bir ECMA5 önerisi mi yoksa AS3’e özgü bir özellik mi olduğunu merak ediyorum
      AS3’teki Dictionary, nesne referanslarını, string’leri ve sayıları benzersiz anahtar olarak kullanıp her türden değeri bağlayabilen bir tipti. Dictionary nesnesinin kendisi yaşadığı sürece zayıf referans olmaması için çöp toplama da buna göre ele alınıyordu
      JavaScript’teki Set’i düşünün; ama belirttiğiniz herhangi bir anahtar türünü güçlü tipli biçimde kullanıyor ve derleme zamanında hata fırlatıyor. O dili özlüyorum
    • Bu yalnızca büyük tarayıcı üreticilerinin meselesi değil. ES6 yeni çıkmak üzereyken bir JavaScript çıkarım motoru yapıyordum ve ES5’i epey destekliyordum; fakat sözdizimi güncellemeleri üst üste gelince vazgeçmek zorunda kaldım
      Bu güncellemeler fiilen JavaScript ekosistemini bozdu ve artık geriye yalnızca JS’e derlenen diller kalmış gibi. Hâlâ vanilla JS kullanan biri, assembly ile uygulama yapan biri gibi duruyor

  • Temporal içinde her saat dilimi verisinin nasıl güncel tutulduğunu merak ediyorum
    TC39 bir yerde verileri güncelliyor ve her tarayıcı bu verileri içine kopyalayıp yeni sürüm mü çıkarıyor; kullanıcı yeni verileri içeren tarayıcıya güncelleme yapmadıysa web sitemde yanlış saati mi görecek, merak ediyorum
    Örneğin Meksika 2022’de yaz saati uygulamasını kaldırdı: https://en.wikipedia.org/wiki/Time_in_Mexico
    pytz veya moment-timezone gibi üçüncü taraf kütüphanelerde sunucu tarafı kütüphaneyi güncellemek yeterli; standart kütüphane ele alıyorsa dil sürümünü yükseltirsiniz. Ama Temporal ve ziyaretçinin tarayıcısında bunun nasıl olacağını bilmiyorum

    • Öneri belgesindeki “Time Zones and Resolving Ambiguity” kısmını okuyunca yalnızca IANA saat dilimi veritabanını kullandığını söylüyor; ne zaman güncellendiği yazmıyor: https://tc39.es/proposal-temporal/docs/timezone.html
      Kullanıcının bilgisayarı da bu veritabanına erişebiliyor ve güncellemeleri ele alıyor olabilir, ama emin değilim. Tarayıcı bu veritabanını ayrıca indirip koruyor da olabilir; uygulamaya göre değişecek gibi
      İlgili veritabanı: https://en.wikipedia.org/wiki/Tz_database
    • Tarayıcıya gömülü bir özellik olduğundan muhtemelen tarayıcı güncellemesi sırasında yenilenecektir. Tarayıcı sağlayıcıları hızlı güncellemeler için çok iş yaptı ve ortalama bir kullanıcının bilgisayarında tarayıcı, en güncel tutulan yazılım olma ihtimali yüksek
    • Tarayıcılar zaten Intl yardımcıları nedeniyle yerel ayarları da güncel tutmak zorunda; o taraf araştırılırsa benzer bir cevap bulunabilir
    • Unix benzeri sistemlerde, yani Linux dağıtımlarında, macOS’te ve Android’de sistem düzeyinde bir IANA Time Zone Database kopyası var. Tarayıcının bunu mu kullandığını yoksa kendi kopyasını mı taşıdığını pek bilmiyorum, ama Temporal kesinlikle IANA tzdb kullanıyor
      Kullanıcı yeni saat dilimi verilerini yansıtmak için tarayıcısını veya sistemini güncellemediyse yanlış saati görebileceği genel olarak doğru görünüyor. Ancak bu, mevcut yaygın uygulamadan pek farklı değil
      Alternatif, her uygulamanın kendi tzdb’sini taşıması olurdu; bazı uygulamalar bunu yapıyor ve haklı olduğu durumlar da var. Ama genelde israf, uygulamalar arası tutarsızlığı artırıyor ve güncelleme döngüsünün de daha yavaş olma ihtimali yüksek
    • Uygulamaya ve sisteme göre değişecektir. Uygulama eninde sonunda bir saat dilimi sağlayıcısı tanımlamak zorunda kalacak; bunun da motor uygulamasının Temporal’a sağladığı host/sistem hook’larından gelmesi muhtemel

  • Birinin saat dilimini değiştirdiğini algılayan bir olay eklemek gerekiyor
    “Programcıların zaman hakkında inandığı yanlışlar” listesine “programcılar kullanım sırasında saat diliminin sabit kaldığına inanır” maddesi de eklenebilir. Gerçekte her gün milyonlarca kişi saat dilimleri arasında hareket ediyor

    • Böyle bir olay, insanları parmak iziyle izlemek ve konumlarını tahmin etmek için başka bir veri noktası olarak kullanılacak gibi görünüyor
    • Bu olayın nerede kullanılacağından pek emin değilim. Zamana bir ölçüde bağımlı olan çoğu web uygulaması için, etkilenen kullanıcı sayısı düşünüldüğünde bu olayı doğrudan dinleyip tepki vermeye değecek mi, şüpheli
      Elbette kütüphaneler için yararlı olabilir
    • İstemcinin saat dilimi yalnızca istemci için önemli olmalı. Zaman damgalarını kullanıcının yerel saatinde gösterme kolaylığı dışında, istemci saatinin önemli hâle geldiği bir koşul yok. Kullanıcı saat dilimini değiştirse de bunu önemsemek için bir neden yok
    • Saat dilimi değişikliğini izlemek durum gerektirdiğinden, geliştiricinin bunu nasıl izleyeceğini ve buna nasıl tepki vereceğini tanımlaması daha doğru görünüyor. Temporal’ın bu işleme biçimi hakkında görüş sahibi olmasını istemeyebiliriz
    • Uçakta ya da ISS’teyseniz, hiç saat diliminizin olmadığı bir durumda bile olabilirsiniz

  • .Now’ın bir fonksiyon çağrısı olmaması çok üzücü. Özellik olmamalı
    Bir döngü içinde .Now birkaç kez değerlendirilirse her seferinde farklı bir değer çıkabilir; bu beklenmedik bir şey
    C# da aynı tercihi yaptı ve yapmamalıydı: https://ericlippert.com/2014/05/19/when-should-i-write-a-pro...

    • Sanırım yanlış anlamışsın. Now, gerçek değerleri alan fonksiyonların ad alanı; örneğin Now.instant() gibi

  • Temporal önerisini gerçekten beğeniyorum ama bir şey takılıyor. Karşılaştırmada referans eşitliğine dayanıyor
    Yani Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') oluyor
    Bu özünde kötü değil, ama bu nesneleri Map anahtarı olarak kullanma ya da Set içinde toplama olanağını fiilen ortadan kaldırıyor. Neden böyle bir karar verdiklerini anlıyorum ama mümkün olmaması üzücü
    Bir gün Records ve Tuples gerçekten çıkarsa, belki buna dayalı bir sürüm oluşabilir

    • JavaScript’in ilkel olmayan tipleri arasında == ile referans dışı eşitliğe sahip olan var mı?
    • Duruma göre .epochMilliseconds değerini Map/Set anahtarı ya da elemanı olarak kullanmak mümkün görünüyor. Ancak Map içinde saat dilimi verisini korumak ya da Instant üzerinde ek işlemler yapmak gerekiyorsa, değer tarafında özgün Instant’ı saklamak gerekir
      Set için Map{v.epochMilliseconds:v} gibi kullanarak Instant’ı koruyabilirsiniz
      Harika değil, ama bu Temporal’dan çok JavaScript’in kendisini suçlamamız gereken bir sorun. Runtime’ın bunu halletmesini de sağlayabilirsiniz, ama o zaman polyfill başarısız olur
    • Mümkün olsa bile, bu tür değerleri Map/Set içinde kullanmak kayan noktalı sayıları Map/Set içinde kullanmaya benzer; genelde kötü bir fikir
    • JavaScript’te imkânsız olduğu için değil mi? Java’daki sabit string havuzu gibi, kullanılan tüm nesnelerin genel bir nesne havuzundaki değerlere referans olmasını sağlayan tuhaf bir hack dışında zor
    • Sadece String() ya da '2020-01-01' kullansak olmaz mı?

  • Mevcut API ile birlikte çalışan bir karşılaştırma fonksiyonu sağlamak sağlam bir tasarım. Yeni bir tip eklerken zorunlu okuma şartı yapılacak kadar iyi
    Örneğin Temporal.Duration.compare’ı sort’a verirseniz PT1H, PT1H30M, PT1H45M, PT2H sırasıyla sıralayabilirsiniz. Tasarımcıları alkışlıyorum

  • Temporal adının Moment, Datetime gibi genel zaman nesneleriyle çakışmayı önleme amacı taşıdığını anlıyorum, ama isim pek iyi değil
    İlk gördüğümde çöp toplama kontrolü gibi bir şey sandım

    • temporal, sonsuzluğun karşıtı olarak zamana dair olan, dilbilgisinde zaman/kip ayrımıyla ilgili olan veya mekândan ayrılan zamanla ilgili olan anlamlarına gelir: https://www.merriam-webster.com/dictionary/temporal
      Kulağa iyi bir isim gibi geliyor
    • Tarayıcı içindeki iş akışı motoru Temporal sandım
    • Zaten verilmiş bir karar üzerine bisiklet kulübesinin rengini tartışmak gibi oluyor, ama gerçekten kötü bir isim olduğuna katılıyorum
      Öncelikle Temporal bir isim değil, sıfat. Zamanla ilgili ama sezgisel olarak tam oturmuyor
      Daha da önemlisi, eski kodlarla çakışma olasılığını azaltmak için garip bir isim seçerseniz, zaman geçtikçe dil daha da opaklaşır
      Promise ve Generator eklendiğinde de bu nesne adlarını kullanan çok sayıda kütüphane vardı. Ayrılmış sözcüklerin aksine yerleşik nesnelerin üzerine yazılabildiği için büyük bir sorun olmadı
      Standart komitesinin dilin uzun vadeli sağlığı için kararlılıkla Time adını kullanması gerektiğini düşünüyorum
      Elbette bu tartışma artık geride kaldı ve tarayıcı üreticileriyle JS motoru uygulayıcıları anlaşmış olmalı
    • Bence de berbat bir isim. DateV2 bile daha iyi olurdu
      Geriye dönük uyumluluğun gerektiğini anlıyorum ama Temporalın tınısı kötü. DateTime JS standardında olan bir isim de değil; neden onu kullanmadıklarını bilmiyorum. O zamana kadar const DateTime = Temporal kullanırım gibi görünüyor

  • İlgili yazılar:
    JavaScript Temporal Is Coming - https://news.ycombinator.com/item?id=42809834 - Ocak 2025, 18 yorum
    Mozilla: Temporal (Limited Availability) - https://news.ycombinator.com/item?id=42776548 - Ocak 2025, 1 yorum
    Is It Time for the JavaScript Temporal API? - https://news.ycombinator.com/item?id=29712118 - Aralık 2021, 100 yorum
    Temporal: Getting started with JavaScript's new date time API - https://news.ycombinator.com/item?id=27661667 - Haziran 2021, 194 yorum
    JavaScript Temporal - https://news.ycombinator.com/item?id=27395236 - Haziran 2021, 1 yorum
    JavaScript Proposal Temporal for Dates is now stage 3 - https://news.ycombinator.com/item?id=26432346 - Mart 2021, 1 yorum

    • Son dönemde Web API’lerin gerçekten harika hale gelmiş olması sevindirici, ama bu konudaki ilk gönderinin neredeyse 4 yıl önce, Mart 2021’de yapılmış olması hâlâ üzücü
      Büyük geminin yön değiştirmesi yavaştır sözü tam da buna uyuyor