From: KOSAKI Motohiro <kosaki.motohiro@...>
Date: 2015-09-30T18:03:09-04:00
Subject: [ruby-dev:49275] Re: [Ruby trunk - Feature #11558] Time related C	APIs

>> 既存の非公開APIを公開してください。
>> struct tm * localtime_with_gmtoff_zone(const time_t *t, struct tm *result, long *gmtoff, const char **zone);
>
> time_t を使うと 2038年問題を考慮しないといけないので、よくないと思います。
> struct tm を使うと (tm_year が int なので) 2**31年問題を考慮しないといけないので、よくないと思います。
> zone を char * で返すのはメモリ管理に責任を持てなくなるので、よくないと思います。

横から失礼します。time_t問題、OS絡みでもあるので、今後の方針とか知りたいです。

まず、time_tが32bitなOSって、いまどのくらい残ってるのでしょうか。わたしの認識だとLinuxとWindowsが
問題ありで、BSDが解決済みだったのですが、あってます？
前にAkrさんが調べてた気がしたのですが、簡単にぐぐった限りでは見つけられませんでした。


現在、Linuxではtime_tに関連するすべてのsyscallに64bit time_t版のsyscallが追加されていっています。
ユーザー空間の以降についてはglibcの対応方針がまだ確定ではないのですが、おそらく 64bit off_tのときのように

１．gettimeofday64() のような64bit time_tのnew syscallが大量にできる
２．TIME_BITS=64 みたいなdefine
（この名前はまだ未確定）をすると、time_tが64bitに差し替わり、自動的にgettimeofday()等もgettimeofday64()を呼ぶよう差し替えられる
３．最終的には TIME_BITS=64 がデフォルトにする

という移行パスになりそう。

さて、この場合に、Rubyがあるメジャー版Upのときに、TIME_BITS=64を追加したら、どのくらいの人がギャっというでしょうか？
いまはバイナリオンリーな拡張なんてないから実は困らない？


そして、もし、TIME_BITS=64 が出来たとして、RubyとしてはメジャーOSがだいたいtime_t問題を解決してくれれば time_t を使い続けるのに
問題ない？
それとも、2038年問題以外にも、ほかに問題ありますか？

というあたりが分かっていないので、識者のご意見うかがわせていただきたく。