Wordpressのアップグレードはとても簡単だから、気軽に出来ちゃう。そしてこれまでの問題のことなどすっかり忘れたころに2.9.2に上げて、またしてもプラグインの時間がUTCに戻ってしまった。

もうこれはこういう仕様なのね。永遠に応急処置を続けていくこともできないので、これはプラグイン側の対応をしないといけないだろう。この問題に対応できるようなWordpressプラグインを作ろうかとも思ったんだけど、新たなプラグインを作るよりも、今のプラグインを直すほうが早いし楽だし。。。

プラグインはphpのtime()で時間をとってきて、アクセス情報とともにテキストファイルに書き出すだけ。Wordpressではdate_default_timezone_set(‘UTC’) が宣言されているため、time()はUTCタイムスタンプを返すようになる。他所で実行するときはJSTタイムスタンプが返される。タイムゾーンを判断して切り替えるよりは、どこで使われようとUTCでタイムスタンプを取得して、JSTに変換するのが簡単で手堅い方法だろう。

ちなみに、プラグイン自体をWebサービスにしてしまえばコードの実行は呼び出し元に寄らないので最もスマートな解なんだけど、大したプラグインでもないのに新たに作り直す必要があって、ちょっとやる気が起きない。

改修は簡単で、time()の前にdate_default_timezone_set(‘UTC’) を宣言して、すぐさまdate_default_timezone_set(‘Asia/Tokyo’) で日本時間に戻す。time()で取得してきたタイムスタンプには9時間足せばいい。date_default_timezone_set('UTC');
$timestamp = time() + 9 * 3600;
date_default_timezone_set('Asia/Tokyo');
これで解決したんだけど、date_default_timezoneを弄るのは後々問題を起こしそうだし、場当たり的なコーディングで美しくない。

よりスマートなUTCタイムスタンプの使い方はそふぃのPHP入門にあるように、$hour = gmdate("H");
$minute = gmdate("i");
$second = gmdate("s");
$month = gmdate("n");
$day = gmdate("j");
$year = gmdate("Y");

$timestamp = mktime($hour, $minute, $second, $month, $day, $year) + 9 * 3600;とすべきかな。

＊ 2010/3/10 追記：
やっぱり他のところに弊害が出て、gmdateを使った方式に変更。これでほぼ不具合は解消できた。本日、昨日のカウントが間違ってるだけ。。。