Whenever – Python için tip ve DST güvenli tarih ve saat işleme tekniği

• Whenever, Python'un datetime yapısını geliştirerek DST güvenliği ve tip güvenliği sunan bir kütüphanedir
• Rust ve saf Python ile kullanılabilir ve performansı yüksektir
• Python standart kütüphanesi ile Arrow ve Pendulum'a kıyasla DST işleme ve tip güvenliği açısından üstündür
• Nanosaniye hassasiyeti ve en güncel GIL iyileştirmelerini destekler, ayrıca Rust uzantısı ile performansı artırır
• MIT lisansı ile sunulur ve geri bildirimler doğrultusunda sürekli geliştirilmektedir

---

Whenever'e Giriş

• Whenever, Python'un datetime modülünün sınırlamalarını aşmak için geliştirilmiş bir kütüphanedir
• DST güvenliği ve tip güvenliği sağlayarak kodun doğruluğunu artırır
• Rust ve saf Python ile uygulanmıştır ve yüksek performans sunar

Standart kütüphanenin sınırlamaları

• Python'un datetime yapısı DST'yi her zaman dikkate almaz
• Tip sistemi içinde naive ve aware datetime türleri ayırt edilemez

Diğer kütüphanelerle karşılaştırma

• Arrow, kullanıcı dostu bir API sunar ancak temel sorunları çözemez
• Pendulum, bazı DST sorunlarını çözmüş olsa da performansı düşer ve bakımı yetersizdir

Whenever'in avantajları

• DST güvenli aritmetik işlemler ve tip güvenli API sunar
• Performansı yüksektir ve Rust uzantısı ile daha da iyileştirilir
• Nanosaniye hassasiyetini ve en güncel GIL iyileştirmelerini destekler

Hızlı başlangıç

• Instant, ZonedDateTime, LocalDateTime gibi açık tipler sunar
• DST güvenli aritmetik işlemler ve açık dönüşümler yapılabilir
• ISO8601, RFC3339, RFC2822 biçimlerinde formatlama ve ayrıştırma desteği sunar

Yol haritası

• 0.x sürümü: özellik eşdeğerliğini sağlama ve API iyileştirmeleri
• 1.0 sürümü: API kararlılığı ve geriye dönük uyumluluğu sağlama

Sınırlamalar

• Milattan sonra 1 ile 9999 yılları arasındaki Gregoryen takvimi destekler
• IANA TZ DB ile uyumlu saat dilimi ofsetlerini destekler
• Artık saniyeler desteklenmez

Sürümleme ve uyumluluk politikası

• Whenever, semantik sürümlemeyi takip eder
• 1.0 sürümüne kadar API değişiklikleri olabilir

Lisans

• MIT lisansı ile sunulur ve Rust bağımlılıkları benzer izin verici lisanslar kullanır

Teşekkür

• Temporal, Noda Time, Joda Time projelerinden ilham alınmıştır
• Ruff projesinin benchmark karşılaştırma grafiği temel alınmıştır

[GN⁺]

Hacker News yorumları

• Bu kütüphanenin neden var olduğunu anlatan blog yazısını henüz okumadıysanız tavsiye ederim. Başlığı şuydu: "Ten Python datetime pitfalls, and what libraries are (not) doing about it"
• Bu kütüphane, standart kütüphanedeki Liskov ihlali sorununu çözüyor. Standart kütüphanede tarihleri karşılaştırabiliyorsunuz ama datetime ile tarihi karşılaştırınca hata oluşuyor. Yakın zamanda işte bu yüzden sıkıntı yaşadım
• Arrow, Delorean, Pendulum ve standart kütüphane datetime kullandım ama sonunda Whenever'ı seçtim. Gerçekten datetime ile çalışmak için daha uygun ve daha aktif biçimde bakımı yapılıyor gibi görünüyor. Diğer kütüphanelerde hep bazı uç durumların gözden kaçtığı hissine kapıldım. Pendulum ise API'nin içine daha derinden işlemiş gibi duruyor
• Standart kütüphaneyi kullanıp belgeleri ve değişiklik günlüğünü dikkatle okuyup ihtiyaç duyduğum özellikleri kendim yazan tek kişi ben miyim? Bağımlılıkların projeyi mahvettiğini zor yoldan öğrendim. Bu, kütüphane iyi değil demek değil tabii. Elbette kullanım alanları var
• Rust veya saf Python olarak sunuluyor. İkili paket kullanma ya da derleme zorunluluğunun getirdiği karmaşıklık, performans avantajına kıyasla buna değmiyor. Saf Python sürümünün kaynak koddan derlenmesi ve özel bayraklar geçirilmesi gerekiyor, bu yüzden requirements.txt içine yazılamıyor
• Performans en önemli öncelik değilse saf Python sürümü de kullanılabiliyor. Saf Python uygulamasının benchmark sonuçlarını da görmek isterdim. Ya Arrow'dan daha yavaşsa?
• Pandas'ın datetime karşılaştırmasını eklememesi ilginç. Muhtemelen diğer kütüphanelerden daha fazla tarih işlemek için kullanılıyordur
• Performans sorunlarının ne zaman önemli olduğunu bilen var mı? datetime'ı kısa ömürlü nesneler olarak düşünüyorum. Kod tabanında binlerce datetime nesnesi olsun istemezsiniz. Neredeyse her durumda UTC yeterli. Aralıkla filtreleme/kümeleme/toplulaştırma gerektiğinde, filtreleme/kümeleme/toplulaştırma ölçütünü ayarlamak için datetime'ı tz ile kullanıp sonra bunu UTC'ye çevirerek int karşılaştırmalarına devam ediyorum. Whenever'ın ele aldığı durumların çoğu herhalde datetime uzun ömürlü bir nesne olduğunda ortaya çıkıyordur. Böyle bir ihtiyacı hiç hissetmedim. İstemciden tz girdisini kabul etmek için kullanıyorum ve gelir gelmez UTC'ye çeviriyorum. Gerçekten tz gerekiyorsa ayrıca saklıyorum. Bu nadiren oluyor (örneğin takvimlerde tz saklanmalı ama muhtemelen her UTC değerinin yanında değil, kullanıcı düzeyinde saklanmalı. Bir başka örnek, personel planlamasında 8am-4pm veya 8pm-4am saatlerinin konuma göre farklı anlamlara gelebilmesi. Bu artık datetime değil, zaman dilimindeki saattir)
• Temel ihtiyaçların ötesine geçmek istediğimde Arrow kullanıyorum. Bu kütüphane oldukça ilginç. Bunun sebebi uç durumları daha geniş kapsaması değil, hem Rustified mod hem de saf Python mod sunması. Whenever kullanınca başka bir şeyi dert etmenize gerek kalmıyor ve projede daha iyi datetime işleme istediğinizde tekrar datetime'a dönmeniz gerekmiyor. Rust araç zinciri olmayan ya da sorunlu ortamlarda da kullanılabiliyor. Tebrikler
• Sanırım sektör/dil genelinde bir test paketi oluşturulmalı. Pek çok tarih/saat/takvim kütüphanesini test edebilecek bir şey. Tarayıcı acid test'lerine benzer ama yalnızca temel işlevlere odaklı. Bu yeni kütüphane hoşuma gitti (teşekkürler) ama adı gerçekte yaptığı şeyin tersini çağrıştırıyor. "Whenever", umursamadığınız anlamına geliyor gibi, ama aslında bunu ancak umursadığınız durumlarda kullanırsınız. Bir de Shakira, haha. Hmm, pedantic zaten kullanılıyor. Timely, precise, punctual, meticulous, ahorita, pronto vb. Zamanla ilgili isimleri seviyorum. Son olarak, bu bağlantıların hiçbirinde değişmezlikten bahsedilmiyor ama en üstte belirtilmesi gerekirdi