Whenever – Python向けの型安全かつDST安全な日付・時刻処理技術

• WheneverはPythonのdatetimeを改善し、DST安全性と型安全性を提供するライブラリ
• Rustと純粋なPythonで利用でき、性能に優れる
• Python標準ライブラリやArrow、Pendulumよりも、DST処理と型安全性の面で優れている
• ナノ秒精度と最新のGIL改善をサポートし、Rust拡張によって性能を向上
• MITライセンスで提供され、フィードバックを通じて継続的に改善中

---

Wheneverの紹介

• WheneverはPythonのdatetimeモジュールの限界を克服するために開発されたライブラリ
• DST安全性と型安全性を提供し、コードの正確性を高める
• Rustと純粋なPythonで実装されており、高い性能を持つ

標準ライブラリの限界

• PythonのdatetimeはDSTを常に考慮するわけではない
• 型システムではnaiveとaware datetimeを区別できない

他のライブラリとの比較

• Arrowは使いやすいAPIを提供するが、根本的な問題は解決していない
• Pendulumは一部のDST問題を解決したものの、性能が低下し、保守も十分ではない

Wheneverの利点

• DST安全な算術演算と型安全なAPIを提供
• 性能に優れ、Rust拡張によってさらに向上
• ナノ秒精度と最新のGIL改善をサポート

クイックスタート

• Instant、ZonedDateTime、LocalDateTimeなどの明示的な型を提供
• DST安全な算術演算と明示的な変換が可能
• ISO8601、RFC3339、RFC2822形式のフォーマットおよびパースをサポート

ロードマップ

• 0.xバージョン: 機能同等性の確保とAPI改善
• 1.0バージョン: APIの安定性と下位互換性の確保

制限

• 西暦1年から9999年までのグレゴリオ暦をサポート
• IANA TZ DBと一致するタイムゾーンオフセットをサポート
• うるう秒はサポートしない

バージョン管理および互換性ポリシー

• Wheneverはセマンティック バージョニングに従う
• 1.0バージョンまではAPI変更の可能性がある

ライセンス

• MITライセンスで提供され、Rust依存関係は同様の許諾ライセンスを使用

謝辞

• Temporal、Noda Time、Joda Timeプロジェクトから着想を得ている
• Ruffプロジェクトのベンチマーク比較グラフを基にしている

[GN⁺]

Hacker Newsのコメント

• このライブラリが存在する理由を説明したブログ記事をまだ読んでいないなら、おすすめする。タイトルは「Ten Python datetime pitfalls, and what libraries are (not) doing about it」
• このライブラリは標準ライブラリのLiskov違反の問題を解決している。標準ライブラリでは日付同士は比較できるが、datetime と日付を比較するとエラーになる。最近この問題のせいで仕事で苦労した
• Arrow、Delorean、Pendulum、標準ライブラリの datetime を使ってみたが、最終的にはWheneverを選んだ。実際に datetime を扱うのにより適していて、より活発にメンテナンスされているように思う。他のライブラリはいつもエッジケースを取りこぼしている感じがした。PendulumはAPIにより深く組み込まれているように見える
• 標準ライブラリを使い、ドキュメントと変更ログを注意深く読み、必要な機能を自分で実装するのは私だけだろうか？ 依存関係がプロジェクトを台無しにすることを痛い目を見て学んだ。このライブラリが素晴らしくないという意味ではない。もちろんユースケースはある
• Rustまたは純粋なPythonで提供されている。バイナリパッケージを使う、あるいはビルドしなければならない複雑さは、性能上の利点に見合わない。純粋Python版はソースからビルドして特別なフラグを渡す必要があるため、requirements.txt に指定できない
• 性能が最優先でないなら純粋Python版も使える。純粋Python実装のベンチマークも見てみたかった。もしArrowより遅いなら？
• Pandasで datetime 比較を追加していないのは面白い。おそらく他のライブラリよりも多くの日付処理に使われているだろうに
• 性能の問題がいつ重要になるのか分かっている人はいるのだろうか？ datetime は短命オブジェクトだと理解している。コードベースに何千もの datetime オブジェクトがある状態は望まないはずだ。ほとんどすべての場合、UTCで十分だ。範囲でフィルタリング／バケット化／集計を行う必要があるときは、フィルタリング／バケット化／集計の基準を設定するためにタイムゾーン付きの datetime を使い、それをUTCに変換して以後は int の比較を続ける。Wheneverが扱うケースの大半は、datetime が長寿命オブジェクトである場合なのだろう。そうした必要性をまったく感じない。クライアントからタイムゾーン入力を受け付けるために使い、受け取ったら即座にUTCへ変換する。本当にタイムゾーンが必要なら別途保存する。これはまれにしか起きない（例: カレンダーではタイムゾーンを保存する必要があるが、おそらく各UTC値の横にすべて保存する必要はなく、ユーザーレベルで保存すべきだ。別の例としては人員スケジューリングで、8am-4pm や 8pm-4am が場所によって異なる意味を持つことがある。これはもはや datetime ではなく、タイムゾーンにおける時刻だ）
• 基本以上のものが欲しいときはArrowを使っている。このライブラリはかなり興味深い。エッジケースのより広いカバレッジのためというより、Rustifiedモードと純粋Pythonモードの両方が提供されているからだ。Wheneverを使えば他のことを心配する必要がなく、プロジェクトでより良い datetime 処理が欲しいときに datetime に戻る必要もない。Rustツールチェーンがない環境や、問題のある環境でも使える。Kudos
• 業界／言語横断のテストスイートを作るべきな気がする。多くの日付／時刻／カレンダーライブラリをテストできるものだ。ブラウザのacid testに似ているが、基本機能だけに焦点を当てる。この新しいライブラリは気に入っている（ありがとう）が、名前は実態と逆の意味を示しているように思う。「Whenever」は気にしないという意味に聞こえるが、実際には気にする場合にしか使わないだろう。それにShakiraもあるし、はは。Hmm、pedanticはすでに使われている。Timely、precise、punctual、meticulous、ahorita、pronto など。時間に関する名前は好きだ。最後に、このリンク群のどれも不変性に触れていないが、それは一番上で言及されるべきだ