Whenever – Kỹ thuật xử lý ngày giờ an toàn về kiểu và DST cho Python

• Whenever là một thư viện cải thiện datetime của Python để cung cấp độ an toàn với DST và độ an toàn về kiểu
• Có thể dùng với Rust và Python thuần, đồng thời có hiệu năng cao
• Vượt trội hơn thư viện chuẩn của Python cũng như Arrow và Pendulum về xử lý DST và độ an toàn về kiểu
• Hỗ trợ độ chính xác nano giây và các cải tiến GIL mới nhất, đồng thời tăng hiệu năng thông qua phần mở rộng Rust
• Được cung cấp theo giấy phép MIT và đang liên tục được cải thiện nhờ phản hồi

---

Giới thiệu về Whenever

• Whenever là thư viện được phát triển để khắc phục các giới hạn của mô-đun datetime trong Python
• Cung cấp độ an toàn với DST và độ an toàn về kiểu để nâng cao tính chính xác của mã
• Được triển khai bằng Rust và Python thuần, với hiệu năng cao

Giới hạn của thư viện chuẩn

• datetime của Python không phải lúc nào cũng tính đến DST
• Hệ thống kiểu không thể phân biệt giữa datetime naive và aware

So sánh với các thư viện khác

• Arrow cung cấp API thân thiện với người dùng nhưng không giải quyết được các vấn đề cốt lõi
• Pendulum đã giải quyết một phần vấn đề về DST, nhưng hiệu năng giảm và việc bảo trì còn hạn chế

Ưu điểm của Whenever

• Cung cấp phép toán số học an toàn với DST và API an toàn về kiểu
• Hiệu năng cao, và còn được cải thiện thêm nhờ phần mở rộng Rust
• Hỗ trợ độ chính xác nano giây và các cải tiến GIL mới nhất

Bắt đầu nhanh

• Cung cấp các kiểu tường minh như Instant, ZonedDateTime, LocalDateTime
• Hỗ trợ phép toán số học an toàn với DST và chuyển đổi tường minh
• Hỗ trợ định dạng và phân tích cú pháp theo các chuẩn ISO8601, RFC3339, RFC2822

Lộ trình

• Phiên bản 0.x: đạt được mức tương đương về tính năng và cải thiện API
• Phiên bản 1.0: đảm bảo tính ổn định của API và khả năng tương thích ngược

Giới hạn

• Hỗ trợ lịch Gregory trong phạm vi năm 1 đến năm 9999
• Hỗ trợ độ lệch múi giờ khớp với IANA TZ DB
• Không hỗ trợ giây nhuận

Chính sách quản lý phiên bản và tương thích

• Whenever tuân theo semantic versioning
• API có thể thay đổi trước phiên bản 1.0

Giấy phép

• Được cung cấp theo giấy phép MIT, còn các phụ thuộc Rust sử dụng giấy phép cấp quyền tương tự

Lời cảm ơn

• Lấy cảm hứng từ các dự án Temporal, Noda Time, Joda Time
• Dựa trên biểu đồ so sánh benchmark của dự án Ruff

[GN⁺]

Ý kiến trên Hacker News

• Nếu chưa đọc bài blog giải thích vì sao thư viện này tồn tại thì rất đáng đọc. Tiêu đề là "Ten Python datetime pitfalls, and what libraries are (not) doing about it)"
• Thư viện này giải quyết vấn đề vi phạm Liskov của thư viện chuẩn. Trong thư viện chuẩn, có thể so sánh các ngày, nhưng nếu so sánh datetime với ngày thì sẽ phát sinh lỗi. Gần đây tôi đã gặp rắc rối ở chỗ làm vì vấn đề này
• Tôi đã dùng Arrow, Delorean, Pendulum và datetime của thư viện chuẩn, nhưng cuối cùng chọn Whenever. Nó thực sự phù hợp hơn để xử lý datetime và có vẻ được bảo trì tích cực hơn. Tôi luôn có cảm giác các thư viện khác đều bỏ sót những trường hợp biên. Pendulum có vẻ ăn sâu hơn vào API
• Có phải chỉ mình tôi dùng thư viện chuẩn, đọc kỹ tài liệu và changelog, rồi tự triển khai tính năng cần thiết không? Tôi đã phải trả giá mới học được rằng dependency có thể phá hỏng dự án. Không phải nói thư viện này không tốt. Dĩ nhiên nó có các trường hợp sử dụng riêng
• Có bản bằng Rust hoặc Python thuần. Độ phức tạp của việc phải dùng gói nhị phân hoặc tự build là không đáng so với lợi ích hiệu năng. Bản Python thuần phải build từ source và truyền các cờ đặc biệt, nên không thể chỉ định trong requirements.txt
• Nếu hiệu năng không phải ưu tiên hàng đầu thì cũng có thể dùng bản Python thuần. Tôi cũng muốn xem benchmark của bản triển khai Python thuần. Nếu nó còn chậm hơn Arrow thì sao?
• Thật thú vị khi Pandas không thêm so sánh datetime. Có lẽ nó sẽ được dùng để xử lý nhiều ngày tháng hơn bất kỳ thư viện nào khác
• Có ai biết khi nào vấn đề hiệu năng thực sự quan trọng không? Tôi hiểu datetime là đối tượng sống ngắn. Bạn hẳn sẽ không muốn có hàng nghìn đối tượng datetime trong codebase. Trong gần như mọi trường hợp, UTC là đủ. Khi cần lọc/gom nhóm/tổng hợp theo khoảng, hãy dùng datetime với tz để thiết lập tiêu chí lọc/gom nhóm/tổng hợp, rồi chuyển nó sang UTC để tiếp tục chỉ so sánh int. Phần lớn các trường hợp Whenever xử lý có lẽ là khi datetime là đối tượng sống lâu. Tôi hoàn toàn không cảm thấy cần điều đó. Tôi dùng nó để chấp nhận đầu vào tz từ client, rồi chuyển ngay sang UTC khi nhận được. Nếu thực sự cần tz, tôi lưu riêng nó. Điều này hiếm khi xảy ra (ví dụ: trong lịch thì cần lưu tz, nhưng có lẽ không cần lưu cạnh mọi UTC mà nên lưu ở cấp người dùng. Một ví dụ khác là lập lịch nhân sự, nơi 8am-4pm hoặc 8pm-4am có thể mang ý nghĩa khác nhau tùy địa điểm. Khi đó nó không còn là datetime nữa mà là thời gian trong một múi giờ)
• Tôi dùng Arrow khi cần nhiều hơn những thứ cơ bản. Thư viện này khá thú vị. Không phải vì nó bao phủ nhiều trường hợp biên hơn, mà vì nó cung cấp cả chế độ Rustified lẫn Python thuần. Dùng Whenever thì không cần lo thứ khác, và khi muốn xử lý datetime tốt hơn trong dự án cũng không cần quay lại datetime. Nó cũng dùng được trong môi trường không có toolchain Rust hoặc môi trường gặp vấn đề. Kudos
• Có lẽ chúng ta nên tạo một bộ test xuyên ngành/xuyên ngôn ngữ. Kiểu có thể kiểm thử nhiều thư viện ngày/giờ/lịch. Tương tự browser acid test nhưng chỉ tập trung vào chức năng cơ bản. Tôi thích thư viện mới này (xin cảm ơn) nhưng cái tên lại gợi nghĩa ngược với thực tế. "Whenever" nghe như không quan tâm, trong khi thực tế chỉ dùng khi bạn có quan tâm. Còn nữa, Shakira, haha. Hmm, pedantic đã được dùng rồi. Timely, precise, punctual, meticulous, ahorita, pronto, v.v. Tôi thích các cái tên liên quan đến thời gian. Cuối cùng, không link nào trong số này nhắc đến tính bất biến, trong khi điều đó đáng ra phải được nhắc ngay từ đầu