アカウント名:
パスワード:
出来上がったもののテストしてたら2038年問題に遭遇しましたよ。会員の有効期限が30年くらいのものがあって、それをテストしたらエラー発生。いろいろと原因を調べていくとどうやら30年有効のはずなのになぜか19xx年までの有効年月と判断されて弾かれてました。
対応してるところは大丈夫と思いますが、長いスパンで見るシステムなんかは(保険とか)気にしてたほうがいいんでしょうね。
# さすがに引退はしてると思うけど、25年後に自分のプログラムを修正する可能性を考えたら今のうちに対応しといたほうがいいんだろうな・・・
Windows と Linux で同じソースのプログラムでソフト作ったら、それぞれで作ったセーブデータに互換性がなくて悩みました。
調べたら、構造体のサイズが違っていたのが原因でした。ヘッダ調べたら、リナックス側の time_t の定義が __time64_t デフォルトになってました。つまり、新しい gcc ライブラリでプログラム組めば対応済みってことかな?
Windows側、Visual C++も2005からtime_tは64-bitがデフォルトになりました。ソースコードがあれば、新しい環境でコンパイルすればとりあえずは良いわけです(ほかで指摘されているように、お行儀の悪いコードでなければ)。
2000年問題が問題になったのは、DBなんかで年を二桁固定にしてたのが多かったからですよね。外部仕様の変更は大仕事です。対応修正の反映更新を全システム同時に行う必要があるし。
一方、2038年がそんな外部仕様レベルで問題になるのは、通信プロトコル、ファイル入出力、DB定義なんかの外部仕様で、32bit型整数でUNIX time をそのまま使っていた場合、なわけですが、そんなことをする該当例はそれほど多くないと思います。DBなら普通はDate型か年月日時分秒にするだろうし。
それなら、あとは時刻を time_t 型として適切に処理するように、という内部処理的な問題なので、外部仕様は変えないまま、順次対応していくことが可能です。time_t が 64bit になったことで、コード無修正の再コンパイルだけで対応できる例も多いでしょう。time_t ではなく int 型を使っているような古くさいコードがあったとしても、time_t に変更することはそれほど難しくないと思います。かなりのソフトランディングになるんじゃないかなぁ。
UNIX time 32bit整数を外部仕様に使ってたとしたら…ご愁傷様です。とりあえずは、符号無し32bitにして2106年までお茶を濁すのかなぁ…C言語だと、符号付64bit→符号無32bitの型変換で値が変わらないことは保証されてるし。
> UNIX time 32bit整数を外部仕様に使ってたとしたら…ご愁傷様です。
ふつーはマルチプラットフォームで「セーブデータの互換性」が必要なときは構造体のバイトイメージを外部仕様なんかにしないと思うんだ。
世の中には・x86は前提にするけどOSは複数・多数派のx86で一番早くなる仕様とかの謎要件もあったりするから、元コメがどうかはわかんないけど、たいていはエンディアン/バイトオーダ/アラインメントが違う実行環境のことをよく知らないタコが仕様切ってトラブル起こす原因になっていたりするわけだが。# 挙句の果てにショボいモバイル端末側ががんばって変換しながらセーブデータ読む羽目になってたりとかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
こないだ遭遇した (スコア:5, 興味深い)
出来上がったもののテストしてたら2038年問題に遭遇しましたよ。
会員の有効期限が30年くらいのものがあって、それをテストしたらエラー発生。
いろいろと原因を調べていくとどうやら30年有効のはずなのになぜか19xx年までの有効年月と判断されて弾かれてました。
対応してるところは大丈夫と思いますが、長いスパンで見るシステムなんかは(保険とか)気にしてたほうがいいんでしょうね。
# さすがに引退はしてると思うけど、25年後に自分のプログラムを修正する可能性を考えたら今のうちに対応しといたほうがいいんだろうな・・・
Re:こないだ遭遇した (スコア:2)
Windows と Linux で同じソースのプログラムでソフト作ったら、
それぞれで作ったセーブデータに互換性がなくて悩みました。
調べたら、構造体のサイズが違っていたのが原因でした。
ヘッダ調べたら、リナックス側の time_t の定義が __time64_t デフォルトになってました。
つまり、新しい gcc ライブラリでプログラム組めば対応済みってことかな?
Re:こないだ遭遇した (スコア:2)
Windows側、Visual C++も2005からtime_tは64-bitがデフォルトになりました。ソースコードがあれば、新しい環境でコンパイルすればとりあえずは良いわけです(ほかで指摘されているように、お行儀の悪いコードでなければ)。
Re:こないだ遭遇した (スコア:1)
2000年問題が問題になったのは、DBなんかで年を二桁固定にしてたのが多かったからですよね。外部仕様の変更は大仕事です。対応修正の反映更新を全システム同時に行う必要があるし。
一方、2038年がそんな外部仕様レベルで問題になるのは、通信プロトコル、ファイル入出力、DB定義なんかの外部仕様で、32bit型整数でUNIX time をそのまま使っていた場合、なわけですが、そんなことをする該当例はそれほど多くないと思います。DBなら普通はDate型か年月日時分秒にするだろうし。
それなら、あとは時刻を time_t 型として適切に処理するように、という内部処理的な問題なので、外部仕様は変えないまま、順次対応していくことが可能です。
time_t が 64bit になったことで、コード無修正の再コンパイルだけで対応できる例も多いでしょう。time_t ではなく int 型を使っているような古くさいコードがあったとしても、time_t に変更することはそれほど難しくないと思います。
かなりのソフトランディングになるんじゃないかなぁ。
UNIX time 32bit整数を外部仕様に使ってたとしたら…ご愁傷様です。
とりあえずは、符号無し32bitにして2106年までお茶を濁すのかなぁ…
C言語だと、符号付64bit→符号無32bitの型変換で値が変わらないことは保証されてるし。
Re: (スコア:0)
> UNIX time 32bit整数を外部仕様に使ってたとしたら…ご愁傷様です。
ふつーはマルチプラットフォームで「セーブデータの互換性」が必要なときは
構造体のバイトイメージを外部仕様なんかにしないと思うんだ。
世の中には
・x86は前提にするけどOSは複数
・多数派のx86で一番早くなる仕様
とかの謎要件もあったりするから、元コメがどうかはわかんないけど、
たいていはエンディアン/バイトオーダ/アラインメントが違う実行環境のことを
よく知らないタコが仕様切ってトラブル起こす原因になっていたりするわけだが。
# 挙句の果てにショボいモバイル端末側ががんばって変換しながらセーブデータ読む羽目になってたりとかな。