すみません。
気のせいかと思っていたのですが、次のうちやはり1.と2.は時間にずれが生じるようなので、一応報告だけしておきます。
ずれが生じるのは0:00 – 9:00までの間で、その間はマイナスの値が増え続ける形になり、9時を境に正しい残り秒数になります。
日付変更から丁度9時間の間だけずれが生じるので時差が関係しているのだと思いますが、具体的な原因はよく分かりません。
// ローカル環境でのテスト
/*
* 1. サーバーのタイムゾーンに関わらずUTC+9を元に今日の残り時間を取得
* 実行速度(1000回試行): 0.0034(秒)
*/
$transient_expiration = mktime( 24, 0, 0 ) - time() - 32400;
/*
* 2. サーバーのタイムゾーンを元に今日の残り時間を取得
* 実行速度(1000回試行): 0.10443(秒)
*/
$transient_expiration = mktime( 24, 0, 0 ) - date_i18n( 'U' );
/*
* 3. 関数date_i18nで取得したUNIX時間の通計秒を元に計算
* 実行速度(1000回試行): 0.10393(秒)
*/
$transient_expiration = 86400 - date_i18n( 'U' ) % 86400;
/*
* 4. 3.の関数date_i18nを関数timeに変更して対応
* 実行速度(1000回試行): 0.00022(秒)
*/
$transient_expiration = 86400 - ( time() + 32400 ) % 86400;
UTC基準の日付と比較してるから起こるんじゃ…(mktimeはwpでは他のdate系関数同様UTC)
date関数よりDateTimeクラス使った方かいい気もしますね…
参考になるかもしれないしならないかもしれない:
http://qiita.com/mpyw/items/ab6e2cf5f64b8a9f3344
http://php.net/manual/ja/datetime.formats.relative.php
ありがとうございます。
UTC基準の日付と比較してるから起こるんじゃ…(mktimeはwpでは他のdate系関数同様UTC)
タイムゾーンがUTCのmktimeと、タイムゾーンを東京に設定したdate_i18n(またはtime() + 32400)では日付変更のタイミングがそれぞれ異なるからずれが生じるという事なのですね…。
これに関してはデフォルトのタイムゾーンを変更する事で解決できました。
// get default time zone
$default_timezone = date_default_timezone_get();
// set new time zone
date_default_timezone_set( 'Asia/Tokyo' );
// get transient expiration
$transient_expiration = mktime( 24, 0, 0 ) - time();
// reset time zone
date_default_timezone_set( $default_timezone );
また、DateTimeクラスが良いとの事なので、頂いたURLを参考に次の様にしました。
DateTimeクラスを使えば2038年問題も解決されるのですね。
// time zone
$timezone = new DateTimeZone( 'Asia/Tokyo' );
// target time
$target_time = date_create( 'tomorrow', $timezone )->format( 'U' );
// current time
$current_time = date_create( 'now', $timezone )->format( 'U' );
// get transient expiration
$transient_expiration = $target_time - $current_time;
しかし、実行速度の速さと得られる結果が変わらない点から、とりあえずは現状のままでいこうと思います。
$transient_expiration = 86400 - ( time() + 32400 ) % 86400;