C言語ケーススタディ C言語に関係の深い2038年問題




2014年10月より個人の方を対象に、Study C無料提供を開始しました。
C言語を勉強中の方は、学習・教育に最適なC言語インタープリタのStudy Cを使ってみてください(個人の方は無料です)。
大学・高専・高校などの教育機関での採用実績も多数あるロングセラー商品Study Cが、個人向けに無料提供を始めました。
インタープリタの手軽さに加え、ゲームや3Dタートルグラフィックで楽しく勉強したりと、C言語の学習を強力にサポートします。
ブロック崩しゲーム 3Dツリー クリスマスツリー
また、このようなボタンの用意されているページでは、掲載しているプログラムをStudy Cに直接ロードし実行したりすることができます。
Study Cにロードする Study Cにロードし編集する Study Cにロードし実行する
Study C無料利用についての詳細は、このページを参照してください。



 2000年が近づくにつれコンピュータの2000年問題が取りざたされていますが、 C言語プログラマにはあまり関係がありません。2000年問題がもっとも深刻な のは大型汎用機のコボルプログラマとハードウェアだと思います。
 C言語プログラマには、2038年問題が待っています。たぶん、2038年問題は あまり深刻ではないと予想していますが、一応念頭に置いておく必要があると 思います。まず、前回作成したget_caltime()関数に次の値を指定して結果を 観察してみましょう(結果は16進数で表示しています)。
#include <stdio.h>
#include <time.h>

time_t  get_caltime(char *tstr);


main()
{
        printf("%x\n", get_caltime("19600101010000"));
        printf("%x\n", get_caltime("20380119121407"));
        printf("%x\n", get_caltime("20380119121408"));
}


time_t  get_caltime(char *tstr)
{
        char    buf[20];
        time_t  cal_time;
        struct tm
                work_tm;

        if(strlen(tstr) != 14)
                return(-1);
        strncpy(buf, tstr, 4);
        buf[4] = '\0';
        work_tm.tm_year = atoi(buf) - 1900;
        strncpy(buf, tstr+4, 2);
        buf[2] = '\0';
        work_tm.tm_mon = atoi(buf) - 1;
        strncpy(buf, tstr+4+2, 2);
        work_tm.tm_mday = atoi(buf);
        strncpy(buf, tstr+4+2+2, 2);
        work_tm.tm_hour = atoi(buf);
        strncpy(buf, tstr+4+2+2+2, 2);
        work_tm.tm_min = atoi(buf);
        strncpy(buf, tstr+4+2+2+2+2, 2);
        work_tm.tm_sec = atoi(buf);
        work_tm.tm_isdst = -1;
        if((cal_time = mktime(&work_tm)) == -1){
                return(-1);
        }
        return(cal_time);
}
Study Cにロードする Study Cにロードし編集する Study Cにロードし実行する ブラウザとの連携機能が使用可能なStudy Cのバージョンなどについて...
1番目と3番目の結果は変換エラーとなるのでFFFFFFFFとなります。 2番目の結果は7FFFFFFFとなります。 カレンダー時刻は1970年からの経過秒数なので、それ以前の日付のデータは取り扱えないの でエラーとなります。3番目は2番目(7FFFFFFF)から1秒経過しているだけなので80000000に なるはずなのですが、エラーとなってしまいます。long変数は80000000から負の数となる のでカレンダー変数では表現できないことになっています。つまり2038年01月19日 12時14分07秒以降カレンダー変数は機能しなくなってしまいます。 もうそろそろ、2038年問題に対する解決方法が統一されてもよいと思うのですが、 今のところ統一した解決方法は決まっていません。
 time_tの定義をunsigned longするか、今後64ビットCPUが主流になってきたら 追加されると思われるlong long型に再定義し、標準関数も修正すればにすれば それほど修正は大変ではないと思います(実際に実験してみたわけではないので はっきりとは解りませんが)。