[ruby-dev:49279] Re: [Ruby trunk - Feature #11558] Time related C APIs
From:
KOSAKI Motohiro <kosaki.motohiro@...>
Date:
2015-10-01 16:10:27 UTC
List:
ruby-dev #49279
2015-10-01 10:27 GMT-04:00 Tanaka Akira <akr@fsij.org>: > 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/ 感触としては、いま time_t の64bit化に着手してないOSは、2038年まで生き残らないと開発元が思ってるってことだから、あまり重要視しなくていいのではないのかという気がしてきています。 >> さて、この場合に、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 を再度使うようになることがあるかどうかはわかりませんが、 > とりあえず利点は感じられません。 Timeクラスが time_t で表すことが現状できないのに、内部表現を time_t に戻すことはないと思います。必要性が感じられない。 > Ruby が提供する Cレベルの API は例によって十分にはそろっていなくて、 > この issue はそれをどうにかしたいという話だと思うのですが、 > まず、アプリケーションがすでに time_t の値を持っているときのために > そこから Time オブジェクトを生成する API はあってもいいでしょう。 > OS から time_t (や timespec) の値を渡されることはよくあるわけですし。 これは同感 > 逆に、Time オブジェクトの情報を完全に取り出したいのであれば time_t を使うのは不可能です。 > 範囲の違いがあるので取り出せない場合があり、time_t で取り出す API をつくるなら、 > 失敗をちゃんと扱えるように設計しなければなりません。 これも賛成。 ただ、ruby独自のtimespecモドキをつくるみたいなアプローチは気に入りません。 ちゃんと時間を扱いたいならTimeオブジェクト作れ一択なので、そう出来ないということは、OSやらまわりのライブラリやらの制約があるケースがほとんどではないかと 推察します。 よって、型としては time_t, struct tm をつかいつつ、ちゃんとコーナーケースを考えて エラー処理をしてくれるAPIがもっともうれしいんじゃないかと思えます。 > そのようにちゃんと設計した上で time_t で十分かという話であれば、 > 64bit time_t なら普通は問題ないんじゃないでしょうか。 > アプリケーションによっては、たとえば比較的最近の過去の時刻 (ログの時刻とか) だけを扱うとか、であれば、 > 32bit time_t でも十分かもしれません。 > でも、32bit time_t を推奨する気にはなりません。 > -- > [田中 哲][たなか あきら][Tanaka Akira]