2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

2038年問題についていち早く考えるスレ

1 :T大学教授:04/01/11 02:01
2038年1月19日にC言語のtime_t関数がオーバーフローします。
どんな事が起こるかはよく分かってないそうです。
どうしましょう。何とかして下さい。

2 :仕様書無しさん:04/01/11 02:02
2get

3 :仕様書無しさん:04/01/11 02:02
良スレあげ

4 :仕様書無しさん:04/01/11 02:03
教授頼りなさすぎだろw

5 :仕様書無しさん:04/01/11 02:06
補足トリビア

C言語では「1970年1月1日0時から何秒経ったか」で時間を表現します。
2038年1月19日(何時何分何秒かは忘れた)はちょうど2^31秒経ちます。
これを超えると時間が表現できないそうです。

6 :仕様書無しさん:04/01/11 02:07
そんなん、dobuleにすればいいんじゃないの?

7 :T大学教授:04/01/11 02:11
補足トリビア2

ちなみに2ちゃんねるのスレッドのアドレスも
「1970年1月1日0時からn秒後に立てられた」という風に決まります。
このスレはhttp://pc.2ch.net/test/read.cgi/prog/1073754075/なので
1970年1月1日0時から1073754075秒後に立てられた、というわけです。
だから2038年問題は2ちゃんねるにとっても重大問題なわけです。たぶん。

8 :仕様書無しさん:04/01/11 02:12
>>6は学生でつか?

9 :仕様書無しさん:04/01/11 02:31
とりあえず64bit化すればOK?

10 :T大学教授:04/01/11 03:07
補足トリビア3

ちなみに2079年問題もあります。

11 :仕様書無しさん:04/01/11 04:30
>>9 そりゃあそうだけど、2000年の場合と違ってアプリケーションレベルの
話ではなくミドルウェアレベルの話だから、単純な解決法を取ろうとすると、

* 今稼働してる全システムの再コンパイルが必要
* それ以前に、言語処理系ベンダーに対応して貰うことが必要


更に、32bitで時間を表している過去のデータ形式との互換性を保つには
手間暇が必要。

12 :◆kR9lpurGm. :04/01/11 04:50
test

13 :仕様書無しさん:04/01/11 05:11
time_t系をどうするかがキモだと思う。
「1970年1月1日0時から何秒経ったか」という基準日時を変更できるように
してもらうのがベストかも知れない。
これ以外の道を取るのであれば、time_t系を全て自前処理系に置き換える
か、64bit化しか無くない?

14 :仕様書無しさん:04/01/11 05:18
基準日時をコロコロ変えたらそれこそ収拾つかなくなるだろ。

15 :13:04/01/11 05:31
>>14
アプリ内で基準日時を設定できれば桶でしょ。
あとは設定日時に基づいてlocaltimeが変換してくれたら桶。

問題は、
*将来的にアプリ固有の年号問題が発生する(その都度基準時変更するだけで桶)
*32bit秒範囲を超える日時を表現しなければならない場合は対処不能

16 :仕様書無しさん:04/01/11 13:22
もうさぁ、64bitとかせこいこと言ってないで128bitでいいじゃん。

17 :さくら組@はにゃ―ん ◆ArasuByydk :04/01/11 13:29
オーバーフローしてもオーバービットフラグを無視つれば

前の時間 - 今の時間

で経過時間はちゃんと取得できるんじゃない。

18 :仕様書無しさん:04/01/11 13:31
まだ30年以上あるんだし、そのころには
もう64bitになってるんじゃないだろうか。

19 :仕様書無しさん:04/01/11 13:47
こういうの、名案を思いついたら、何処に言えばいいの?

20 :仕様書無しさん:04/01/11 14:05
とりあえず the Open Group とか

21 :仕様書無しさん:04/01/11 14:53
オラクルなんかでも248日問題とかあるよな。

22 :仕様書無しさん:04/01/11 15:01
つーか、この話題もう何度も何度も何度も議論されてて結論でまくりなんだけど。

23 :仕様書無しさん:04/01/11 15:38
IETFではすでに10000年問題の解決策まで考えられている。
RFC2550(日本語訳) http://www.imasy.or.jp/~yotti/rfc-joke.html

このさい今のうちからRFC2550を導入とくべきだろう。

24 :仕様書無しさん:04/01/11 16:21
23レス目でようやく例のRFCか。マ板も落ちたな。

25 :T大学教授:04/01/11 16:26
#include <stdio.h>

void main()
{
int n = 1;
while (n > 0) {
printf("逝ってよし!\n");
}
}



とりあえずこれコンパイル&実行してみて下さい。

26 :仕様書無しさん:04/01/11 16:28
>>25
コンパイルエラーだよ

27 :仕様書無しさん:04/01/11 16:41
class CTime
{
 private: UInt128 m_Time;
 public: operator TIME_T() const { return m_Time; }
};

28 :仕様書無しさん:04/01/12 11:22
まだ30年以上あるんだし、そのころには藻前らはもう(ry

29 :仕様書無しさん:04/01/12 11:40
間違いなくダンボール生活の果てに凍死しているものとは
思うが、2000年問題の轍をふまぬよう コメントに

// 2038年問題のメンテごくろうさま

と入れておく

30 :仕様書無しさん:04/01/12 11:49
>>29
ぬっ殺す。

31 :仕様書無しさん:04/01/12 17:20
>>24
ジョークRFC以外のRFCを知らん厨房が大口叩いてる

32 :仕様書無しさん:04/01/12 17:33
とりあえず>>1の「time_t関数」には誰も突っ込まなくていいのか。

33 :仕様書無しさん:04/01/12 19:44
>>29
心配しなくても、とっくに廃棄されてるよ。

34 :仕様書無しさん:04/01/12 20:04
Y2Kのときも1960年代には誰もがそう思ったんだ。

35 :仕様書無しさん:04/01/12 20:10
>>34
そして、のり越えた。

36 :仕様書無しさん:04/01/12 23:42
>>1
Javaでプログラミングする。
JVMを改造して一件落着。
改造するスキルがあるならね

37 :仕様書無しさん:04/01/14 02:31
>>25
とりあえずmain()はintにしとこうか

38 :仕様書無しさん:04/01/22 00:58
またスレが一つ死んだ。

39 :仕様書無しさん:04/02/03 21:42
死んでなかったああああああああ
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20040202/139212/
【スクープ】コンピュータの“西暦2038年問題”発生、早くも日本を揺るがす

40 :仕様書無しさん:04/02/03 22:56
ATMだろ。2倍処理ってどんなこと?

41 :仕様書無しさん:04/02/03 23:34
>>39
> この問題が起きた銀行はいずれも日本IBMのソフトを使っていたが、このソフトの内部に、
> 時刻の2倍に足し合わせる処理があり、ちょうど1970年と2038年1月19日の2分の1を超えた
> 2004年1月11日の朝から、2038年問題が顕在化して、システムが正常に稼動しなくなった。

一体どんなバカがそんなコードを書いたんだ?


42 :仕様書無しさん:04/02/04 00:51
そのころは61歳だから問題ないっす!。

43 :仕様書無しさん:04/02/04 01:10
65歳まで雇用するようにっていう法律が今出来ようとしているんだけど・・・

44 :仕様書無しさん:04/02/04 01:29
>>40
(a+b)/2;
で平均をとる処理っぽいが、
ATMで二つの日時の中間を計算する必要ってあるかな?

45 :仕様書無しさん:04/02/04 13:19
>>44
俺も思った
時刻を2倍に足し合わせるって
どういう処理のための演算なのだろうか

46 :仕様書無しさん:04/02/04 13:36
全国規模でトラぶったから、法律でなんかそういう処理にならざるを得ない部分があるんだろな。

47 :仕様書無しさん:04/02/04 16:29
VS.NETの場合

#define time_t __int64

となっているんだが何か?

48 :仕様書無しさん:04/02/04 17:09
どうせ俺は死んでるか隠居してるかだから関係ない。

49 :仕様書無しさん:04/02/04 17:12
まだCOBOLが使われてたりしてな(藁

50 :仕様書無しさん:04/02/04 17:40
>>46
トラぶったの全部IBM製らしいから、IBMが使いまわしただけでしょ。

>>47
epochってUNIX C固有の問題だから、
最近出たMS製品でそうなっているのは、何も問題ない
っていうか、関係ない。

51 :仕様書無しさん:04/02/04 22:24
>>47 んぢゃ、今動いてるアプリを片っ端からリコンパイルして入れ替えといてね

52 :仕様書無しさん:04/02/04 22:55
>>44
定期預金の中間利払い日でも計算していたっていう推論はどう?
中間利払い日以前の解約は窓口での取り扱いということで、それ以前のものはATMでは受け入れないとか?
ちょっとこじつけっぽいけどね。

53 :仕様書無しさん:04/02/04 23:22
>>44 無限に大きなタイムアウト待ち

54 :仕様書無しさん:04/02/04 23:31
大丈夫、どんな問題でも
いつでも根拠のない自身ッたっぷりなチビロンゲが
解決してくれるよ。
安心、安心(´▽`*)あはは

55 :仕様書無しさん:04/02/22 11:31
だから 循環させて処理すればいいじゃない。

今年を基準にしてのモジュラー計算をいつもさせりゃいいだけでしょ?

といっても今年をどこかに覚えておく必要があるからそれを標準化してかないといけないが

56 :47:04/02/22 12:47
しまった。

typedef __int64 time_t

だった。

そうか、現在稼動中のシステムを全て変えるのは、難しそうだなぁ。

57 :仕様書無しさん:04/03/09 00:51
>>56
あと30年強の間に、いったいいくら入れ替えのチャンスが
あると思ってるんだよ。
あと、なにも一変数で管理しないといけない法律でもあるのかよ。
別に8bit符号無し整数配列で時間表現しても良かろうに。

10 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)