Whenever – Teknik penanganan tanggal dan waktu yang aman secara tipe dan DST untuk Python

• Whenever adalah library yang meningkatkan datetime Python dengan menyediakan keamanan DST dan keamanan tipe
• Dapat digunakan dengan Rust dan Python murni, serta memiliki performa yang sangat baik
• Lebih unggul daripada pustaka standar Python serta Arrow dan Pendulum dalam penanganan DST dan keamanan tipe
• Mendukung presisi nanodetik dan peningkatan GIL terbaru, serta meningkatkan performa melalui ekstensi Rust
• Tersedia dengan lisensi MIT dan terus ditingkatkan melalui umpan balik

---

Pengenalan Whenever

• Whenever adalah library yang dikembangkan untuk mengatasi keterbatasan modul datetime di Python
• Menyediakan keamanan DST dan keamanan tipe untuk meningkatkan keakuratan kode
• Diimplementasikan dalam Rust dan Python murni, serta menawarkan performa yang sangat baik

Keterbatasan pustaka standar

• datetime Python tidak selalu mempertimbangkan DST
• Dalam sistem tipe, naive dan aware datetime tidak dapat dibedakan

Perbandingan dengan library lain

• Arrow menyediakan API yang ramah pengguna, tetapi tidak menyelesaikan masalah inti
• Pendulum menyelesaikan sebagian masalah DST, tetapi performanya menurun dan pemeliharaannya kurang

Kelebihan Whenever

• Menyediakan operasi aritmetika yang aman terhadap DST dan API yang aman secara tipe
• Performanya sangat baik, dan semakin meningkat melalui ekstensi Rust
• Mendukung presisi nanodetik dan peningkatan GIL terbaru

Mulai cepat

• Menyediakan tipe eksplisit seperti Instant, ZonedDateTime, dan LocalDateTime
• Mendukung operasi aritmetika yang aman terhadap DST dan konversi eksplisit
• Mendukung formatting dan parsing format ISO8601, RFC3339, dan RFC2822

Roadmap

• Versi 0.x: mencapai kesetaraan fitur dan meningkatkan API
• Versi 1.0: memastikan stabilitas API dan kompatibilitas mundur

Keterbatasan

• Mendukung kalender Gregorian dari tahun 1 hingga 9999 Masehi
• Mendukung offset zona waktu yang sesuai dengan IANA TZ DB
• Detik kabisat tidak didukung

Kebijakan versi dan kompatibilitas

• Whenever mengikuti semantic versioning
• Sebelum versi 1.0, API masih dapat berubah

Lisensi

• Tersedia dengan lisensi MIT, dan dependensi Rust menggunakan lisensi permisif serupa

Ucapan terima kasih

• Terinspirasi dari proyek Temporal, Noda Time, dan Joda Time
• Berdasarkan grafik perbandingan benchmark dari proyek Ruff

[GN⁺]

Komentar Hacker News

• Jika belum membaca posting blog yang menjelaskan alasan keberadaan library ini, saya merekomendasikannya. Judulnya adalah "Ten Python datetime pitfalls, and what libraries are (not) doing about it"
• Library ini memperbaiki masalah pelanggaran Liskov pada standard library. Di standard library, tanggal bisa dibandingkan, tetapi jika datetime dibandingkan dengan tanggal akan terjadi error. Baru-baru ini saya kesulitan di tempat kerja karena masalah ini
• Saya sudah mencoba Arrow, Delorean, Pendulum, dan datetime dari standard library, tetapi pada akhirnya memilih Whenever. Rasanya memang lebih cocok untuk menangani datetime, dan tampaknya dipelihara lebih aktif. Saya selalu merasa library lain melewatkan edge case. Pendulum terasa lebih tertanam dalam API
• Apa saya satu-satunya yang memakai standard library, membaca dokumentasi dan changelog dengan saksama, lalu mengimplementasikan fitur yang dibutuhkan? Saya belajar dengan susah payah bahwa dependensi bisa merusak proyek. Bukan berarti library ini tidak bagus. Tentu ada kasus penggunaannya
• Tersedia dalam Rust maupun Python murni. Kerumitan karena harus memakai atau membangun paket biner tidak sepadan dengan manfaat performanya. Versi Python murni harus dibangun dari source dan perlu mengirim flag khusus, jadi tidak bisa ditentukan di requirements.txt
• Jika performa bukan prioritas utama, versi Python murni juga bisa dipakai. Saya juga ingin melihat benchmark implementasi Python murninya. Bagaimana jika performanya lebih buruk daripada Arrow?
• Menarik bahwa Pandas tidak menambahkan perbandingan datetime. Kemungkinan justru dipakai untuk menangani lebih banyak tanggal daripada library lain
• Adakah yang tahu kapan masalah performa benar-benar penting? Saya memahami datetime sebagai objek berumur pendek. Saya tidak ingin ada ribuan objek datetime di codebase. Dalam hampir semua kasus, UTC sudah cukup. Saat perlu memfilter/membagi bucket/mengagregasi berdasarkan rentang, saya memakai datetime dengan tz untuk menetapkan kriteria filter/bucket/agregasi, lalu mengonversinya ke UTC dan tetap melakukan perbandingan int. Sebagian besar kasus yang ditangani Whenever tampaknya adalah saat datetime menjadi objek jangka panjang. Saya sama sekali tidak pernah merasakan kebutuhan itu. Saya memakainya untuk menerima input tz dari klien, lalu langsung mengonversinya ke UTC saat diterima. Jika benar-benar perlu tz, saya simpan terpisah. Ini jarang terjadi (misalnya: pada kalender, tz memang harus disimpan, tetapi mungkin tidak perlu disimpan di samping setiap UTC, cukup di level pengguna. Contoh lain adalah penjadwalan tenaga kerja, di mana 8am-4pm atau 8pm-4am bisa berarti berbeda tergantung lokasi. Itu bukan lagi datetime, melainkan waktu dalam suatu zona waktu)
• Saya memakai Arrow saat menginginkan sesuatu yang lebih dari dasar. Library ini cukup menarik. Bukan karena cakupan edge case yang lebih luas, melainkan karena menyediakan mode Rustified dan mode Python murni. Dengan Whenever, saya tidak perlu khawatir soal hal lain dan tidak perlu kembali ke datetime saat menginginkan penanganan datetime yang lebih baik di proyek. Ini juga bisa dipakai di lingkungan tanpa toolchain Rust atau di lingkungan yang bermasalah. Kudos
• Rasanya kita perlu membuat test suite lintas industri/bahasa. Sesuatu yang bisa menguji banyak library tanggal/waktu/kalender. Mirip browser acid test, tetapi berfokus hanya pada fungsi dasar. Saya suka library baru ini (terima kasih) tetapi namanya menyiratkan makna yang kebalikan dari kenyataannya. "Whenever" terdengar seperti tidak peduli, padahal sebenarnya saya hanya akan memakainya saat memang peduli. Juga Shakira, haha. Hmm, pedantic sudah dipakai. Timely, precise, punctual, meticulous, ahorita, pronto, dan sebagainya. Saya suka nama yang terkait waktu. Terakhir, tidak ada satu pun dari tautan ini yang menyebut immutability, padahal itu seharusnya disebut paling atas