（箸休め）時間管理ルーチン・シリアル値の特異点

（箸休め）時間管理ルーチン・シリアル値の特異点

　今日、Ｃ言語の時間管理ルーチンをいじってて気づいた点があった。
　シリアル値の頭が1234になってる！
　だから何？と言う声が聞こえそうなので、もう少し詳しく説明しておこう。

　Ｃ言語の時間管理ルーチンはtime_tというシリアル値を用いて行っている。
　UNIXの仕様に端を発しているのだが、このシリアル値は多くの処理系では1970年1月1日0時0分0秒（標準時）からの経過秒数である。シリアル値はtime_tという型に入れて使用するが、この型が32ビット負号無し整数に割り当てられている処理系であれば、2038年1月19日3時14分7秒（標準時）に桁あふれを起こしてしまうため、使用できなくなってしまう。これは2038年問題と言われ結構深刻な問題だが、まだ先の話であるため「コンパイラが何とかしてくれるんじゃない？」ぐらいの感じで流されている（が、実際は一時騒がれた2000年問題よりも深刻という話もある）。

参考（2038年問題）：
Wikipedia：2038年問題

　で、今日プログラムをいじってて、シリアル値の頭が1234になっていることに気づいたので、調べてみたところ

2009年2月13日23時31分30秒（標準時）
2009年2月14日8時31分30秒（日本時間）

　で、シリアル値が

1234567890

　になる事が分かった！！

　一応、確認したソースを上げておく

#include <stdio.h>
#include <time.h>

int main()
{
      time_t timeRen = 1234567890;
      struct tm tmUTC;
      struct tm tmJPN;

      tmJPN = *localtime( &timeRen );
      tmUTC = *gmtime( &timeRen );

      printf( "(UTC)%d/%d/%d %d:%d:%d¥n"
            , tmUTC.tm_year+1900 , tmUTC.tm_mon+1 , tmUTC.tm_mday
            , tmUTC.tm_hour , tmUTC.tm_min , tmUTC.tm_sec );

      printf( "(JPN)%d/%d/%d %d:%d:%d¥n"
            , tmJPN.tm_year+1900 , tmJPN.tm_mon+1 , tmJPN.tm_mday
            , tmJPN.tm_hour , tmJPN.tm_min , tmJPN.tm_sec );

      return 0;
}

　テンション上がるよね！！
　え？俺だけ？理解できない？ま、確かにそうかも．．．

　まあ、シリアル値に関しては閏年は計算に入れているけど、たまに入る閏秒は計算に入れていないから、実際の経過秒数とは若干違うんだけど、1970年1月1日からひたすら刻んできた時計が、「1234567890」って言う連番になる瞬間を見届けるのもいいのではないでしょうか？

参考（閏秒）：
Wikipedia：閏秒

追記
この記事を書いた後、色々調べていたら、既出でしたね（当然と言えば当然ですが）
Wikipedia:time_tパーティー