n.yamamoto
2014年12月15日 18時30分
Yamamotoです。
毎々お世話になっております。
Armadillo-460で、旧のシステムをatmark-dist-20141128とlinux-2.6.26-at20で機能変更して動かそうとしています。
でお客様から2038年問題について確認が合ったのですが・・・
現状2038年問題に対する対応は何も入っていないのでしょうか？
フォーラムを調べたのですが、古くに非対応のコメントしか見つかりませんでした。
2038年問題に関して何か対応をされたことのある方法とかでも構いませんのでありましたら教えてください。
コメント
n.yamamoto
> > でお客様から2038年問題について確認が合ったのですが・・・
> > 現状2038年問題に対する対応は何も入っていないのでしょうか？
>
> ごめんなさい。入っていません。
>
> Linux 3.17 でも完全に対応できていません。
> http://lwn.net/Articles/607741/
> https://jp.linux.com/news/linuxcom-exclusive/422498-lco2014101701
何か回避策を講じたという情報はありませんか？
at_yashi
ごめんなさい。イマイチご質問の意図を理解できてないです。
もう少し詳しく教えていただけますか？
Linuxカーネルは、対策が始まった状態です。
先に貼ったリンクは、カーネル内部で時間を表現している ktime_t と
timespec の修正の説明です。
内部が決まれば、次はユーザー側への APIです。たとえば↓です。
http://thread.gmane.org/gmane.linux.kernel/1715110
カーネルの内部とAPIが決ったらユーザーランド側で修正を始めることができ
るようになります。libc など主要ライブラリの修正が入り、その後アプリケー
ションが修正可能になります。
http://kernelnewbies.org/y2038
Linuxではないですが、OpenBSD や NetBSDはすでに 64bit の time_t に移行
したみたいですね。
- http://www.openbsd.org/55.html
- http://www.netbsd.org/releases/formal-6/NetBSD-6.0.html
n.yamamoto
Yamamotoです。
> ごめんなさい。イマイチご質問の意図を理解できてないです。
> もう少し詳しく教えていただけますか？
済みません。
お客様から、新規に造るシステムで2038年問題に対して事前に対処が
可能なのかどうかの確認がありました。
おそらく24年後の事なので、担当された方が忘れずに引きついで行けてれば
問題ないのですが、できれば仕事として完結しておきたいとの思いだと思われます。
なので、現状でOSのバージョンアップ等方法とかで可能な方法があるのか無いのか
の確認がしたかっただけです。
合わせて、どこかのお客様でファイル日付は狂うけどRTCを-100年して使ってますとか
(ちょっと現実的ではないですが)何かローカルな方法でも講じられたというような情報が
あればと思いまして・・・
言葉足らずで済みません。
izawa
n.yamamoto
at_yashi
2014年12月15日 18時37分
> でお客様から2038年問題について確認が合ったのですが・・・
> 現状2038年問題に対する対応は何も入っていないのでしょうか？
ごめんなさい。入っていません。
Linux 3.17 でも完全に対応できていません。
http://lwn.net/Articles/607741/
https://jp.linux.com/news/linuxcom-exclusive/422498-lco2014101701