[ruby-dev:49278] Re: [Ruby trunk - Feature #11558] Time related C APIs
From:
Tanaka Akira <akr@...>
Date:
2015-10-01 14:27:52 UTC
List:
ruby-dev #49278
2015年10月1日 7:03 KOSAKI Motohiro <kosaki.motohiro@gmail.com>: > 横から失礼します。time_t問題、OS絡みでもあるので、今後の方針とか知りたいです。 方針はないんじゃないですかね。 具体的な問題を発見することから始まるのではないでしょうか。 > まず、time_tが32bitなOSって、いまどのくらい残ってるのでしょうか。わたしの認識だとLinuxとWindowsが > 問題ありで、BSDが解決済みだったのですが、あってます？ > 前にAkrさんが調べてた気がしたのですが、簡単にぐぐった限りでは見つけられませんでした。 NetBSD 6.0 と OpenBSD 5.5 は解決済みで、32bit 環境でも time_t は 64bit です。 http://www.netbsd.org/releases/formal-6/NetBSD-6.0.html http://www.openbsd.org/55.html FreeBSD は確認できませんでした。 DragonFly BSD は 4.0 以降は 32bit 環境をサポートしないそうなので問題ないでしょう。 https://www.dragonflybsd.org/release40/ > さて、この場合に、Rubyがあるメジャー版Upのときに、TIME_BITS=64を追加したら、どのくらいの人がギャっというでしょうか？ > いまはバイナリオンリーな拡張なんてないから実は困らない？ 私の感覚としては、マイナーバージョンアップのときに変えてもいいんじゃないかと思いますが。 > そして、もし、TIME_BITS=64 が出来たとして、RubyとしてはメジャーOSがだいたいtime_t問題を解決してくれれば time_t を使い続けるのに > 問題ない？ > それとも、2038年問題以外にも、ほかに問題ありますか？ えぇと、Ruby 1.9.2 以降の Time クラスは内部的に Bignum や Rational を使えるので、 64bit time_t でも表現できないものや、ナノ秒よりも小さい秒も表現できます。 localtime 関数で地方時の情報を求めるときには (あと閏秒の情報を求めるときに) time_t が必要ですが、それ以上には依存していないはずです。 time_t や localtime の都合で地方時や閏秒の情報を得ることが無理なときには外挿します。 Linux と glibc が 64bit time_t を提供するのは歓迎です。 外挿しなければならない範囲を減らせるでしょう。 でも、たとえ 64bit time_t でも、Bignum に比べれば狭い範囲しか扱えない以上、 外挿が不要になるわけではありません。 Ruby が Time クラスの内部表現に time_t を再度使うようになることがあるかどうかはわかりませんが、 とりあえず利点は感じられません。 Ruby が提供する Cレベルの API は例によって十分にはそろっていなくて、 この issue はそれをどうにかしたいという話だと思うのですが、 まず、アプリケーションがすでに time_t の値を持っているときのために そこから Time オブジェクトを生成する API はあってもいいでしょう。 OS から time_t (や timespec) の値を渡されることはよくあるわけですし。 逆に、Time オブジェクトの情報を完全に取り出したいのであれば time_t を使うのは不可能です。 範囲の違いがあるので取り出せない場合があり、time_t で取り出す API をつくるなら、 失敗をちゃんと扱えるように設計しなければなりません。 そのようにちゃんと設計した上で time_t で十分かという話であれば、 64bit time_t なら普通は問題ないんじゃないでしょうか。 アプリケーションによっては、たとえば比較的最近の過去の時刻 (ログの時刻とか) だけを扱うとか、であれば、 32bit time_t でも十分かもしれません。 でも、32bit time_t を推奨する気にはなりません。 -- [田中 哲][たなか あきら][Tanaka Akira]