ノート:2038年問題
 | 出典検索?: "2038年問題" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · ジャパンサーチ · dlib.jp · ウィキペディア図書館 |
仕様上では符号サイズは規定されていないということは、C言語処理系の実装の問題ということになるでしょうかHoge- 07:34 2003年5月1日 (UTC)
C言語以外に2038年問題になる言語はないのでしょうか？また、1970年1月1日0時（世界標準時、日本時間では9時）からの経過秒数を使用しているＯＳ（UNIT以外）もあるのでしょうか？
time_t は size_t とは関係ない 編集
C言語規格の 7.23.1 の記述は、単に「time.h ヘッダをインクルードすると size_t, time_t, clock_t 型が宣言される」といっているだけであって、別に「time_t 型は size_t 型と同じ型である」とはいっていません。size_t 型に関する記述は明らかに誤読に基づくものなので削除しました。--まじかんと 2008年2月11日 (月) 07:31 (UTC)
そもそもtime_tはどうしてsigned long int型だったのか？ 編集
今更感があるような気もしますが、そもそもtime_tはどうしてsigned long int型だったのでしょうか？unsigned longならば問題をあと約70年先延ばしできたような気がするのですが。
負数による1970年以前の表現が必要だったのでしょうか？--78.83.72.47 2011年10月28日 (金) 18:27 (UTC)
- time_tの根幹であるところの、UNIX/標準Cライブラリのtime()関数は、エラーの場合に(time_t)-1を返す仕様になっています。-1を返すために符号付きにしたのか、符号付きにしたから-1をエラーにしたのかはわかりませんが、負の値も使われていることはたしかです。--124.45.152.67 2011年11月17日 (木) 07:32 (UTC)
2038年1月19日3時14分7秒 編集
これはUTCの場合ですよね。日本時間JSTも併記しないと誤解が生じると思うのですが。閏秒云々で括弧を使ってしまったので上手い書き方が思いつきません。--219.104.87.4 2011年12月10日 (土) 06:14 (UTC)
試した結果 編集
C言語で簡単なコードを書いて試してみましたが、32ビット環境のGCCの場合、Cygwin、MinGW、Linux、FreeBSDと試しましたが全部ダメ(符号付き32ビット)でした。但し、64ビット環境のLinuxだと time_t も64ビットになります。ほかにVisual C++も64ビットになっています(32ビット環境のWindows 7での話)。その他、Digital Mars C、Borland C++ Compiler、Tiny C Compilerも試しましたが全てダメでした。Open Watcom は何故か32ビット符号なし整数になっているようです。SDCCでも試したのですがコンパイルできず断念しました。--MihailJP（会話） 2012年10月8日 (月) 22:59 (UTC)
- 更に調べてみましたが、DMCの場合time_tがマイナスになるとgmtimeがNULLを返すようです。VC++、GCC、Open Watcomも試しましたがマイナスでもgmtimeは動くには動きます(Open Watcomの場合マイナスにはならないのですが)。--MihailJP（会話） 2012年10月9日 (火) 06:32 (UTC)
- Wikipediaとしては、上記の事は{{独自研究}}と言うしかないですね。エラー回避の検証も方が大事かと思われます。あとは記事で64ビットOSの記事脚注で検証するしかないでしょう。--水瀬悠志（会話） 2019年4月22日 (月) 21:52 (UTC)