MySQLに時刻を格納するのに迷っている。SDBBSIIはunixtime、SDBBSはY/m/d H:i形式のtext、DBBSのy/m/d H:i形式のtext。unixtimeのほうが何かと便利だが、2023年以降データが使えなくなっても困る。unixtimeは32bitだから、1970/01/01 00:00:00からの積算秒数が2023年以降カウンタリセットされる。
この問題はPostgreSQLでは64bitに拡張しているようだが、MySQLでは対応されていないようだ。
一応、過去のtextベースのdatファイルに記録されたフォーマットは、「2001/10/20」みたいな形式だったのが幸いした。たとえば、2バイト文字で曜日が入っていたらstrtotime()では変換できない。
$temptimeSDB = “2002/07/15 08:37”;
$db = strtotime ($temptimeSDB);
print “SDBの変換前文字列は”.$temptimeSDB.”
“;
print “UnixTimeに変換すると”.$db.”
“;
$reformat =date (“Y/m/d(D) H:i:s”,$db);
print “これを再フォーマットすると”.$reformat.”
“;
まぁ、こんなテストをしてphpは本当にイージーだと認識する次第。
日付検索をするならunixtimeのほうがリソースの消費が抑えられるはずだ。だが、2023年を気にするなら文字列で出力して置き、将来のstrtotime()の64bit拡張に期待することもできる。このプランをとった場合は日付検索でややリソースが多くなる気がするが、検索もどうせstrtotime()で引き渡すから関係ないだろうか?
まずは、PHPはしらないですが、unixtime (32ビット)の最終時刻は2038にある。この日付はプログラマの心に刻んでいるぜ。
irb(main):026:0> Time.at(0x7FFFFFFF)
=> Tue Jan 19 12:14:07 Tokyo Standard Time 2038
この後はなにもない!クリスト教の蘇ること?!?
irb(main):025:0> Time.at(0x80000000)
RangeError: bignum too big to convert into `long’
from (irb):25:in `at’
from (irb):25
これはMYSQLの問題ではなく、PHPの問題です。(たとえば、PostgresQLでもこの問題は起こりえる。)MYSQL5.1のHPによると、たとえばTIMESTAMP型で、9999-12-31 23:59:59まで対応している。(時差は気をつけましょう、が)
http://dev.mysql.com/doc/refman/5.1/en/datetime.html
http://jp2.php.net/strtotime
この時はMVC(Model View Controller)の概念を使ったほうが良い。MはデータベースでDATETIME型やTIMESTAMP型で日付情報を管理し、時刻関連計算はDBに任せる。表示と入力はVとCでPHP側で管理すれば良い。しかし、PHPはこのところで未熟ので、時刻はテキストとしてMYSQLにまで渡し、変換してもらう。
ということで、とりあえずtextでやろう。試してみた限りではstrtotime()使えばなんとでもなる気がする。