BugTrack/2077
の編集
Top
/
BugTrack
/
2077
[
トップ
] [
編集
|
差分
|
履歴
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
RIGHT:&size(12){Category:[[:Plugin]]}; *showrss のタイムスタンプの処理が冗長 [#nb4b98b4] -ページ: [[BugTrack2]] -投稿者: [[upk]] -優先順位: 低 -状態: 提案 -カテゴリー: プラグイン -投稿日: 2005-06-04 (土) 21:49:54 -バージョン: **メッセージ [#u793c027] plugin_showrss_get_timestamp の処理において、タイムスタンプの処理が冗長になっていますので、strtotime() に任せるようにしました。 --- showrss.inc.php.ORG 2005-06-04 21:43:58.485997780 +0900 +++ showrss.inc.php 2005-06-04 21:45:16.359433684 +0900 @@ -298,12 +298,11 @@ $time = strtotime($str); return ($time == -1) ? UTIME : $time - LOCALZONE; } - $str = $matches[1]; - $time = strtotime($matches[1] . ' ' . $matches[2]); + $str = $matches[1] . ' ' . $matches[2]; if (! empty($matches[3])) { - $diff = ($matches[5] * 60 + $matches[6]) * 60; - $time += ($matches[4] == '-' ? $diff : -$diff); + $str .= ' ' . $matches[4].$matches[5].$matches[6]; } + $time = strtotime($str); return $time; } ?> ちょっとデバッグしていたんですが、従来のこの処理って、うまく機能していないような感じです。確認してみて下さい。とりあえず、冗長としておきますが。 ---- -お疲れ様です。とりあえず元のコードのempty()はisset()が適切なようで、if(preg_match)のブロックをくくり直した方が良さそうですね(でないとなぜ下の部分だけstrtotime()の返り値をチェックしていないのかがパッと見わからない)。また時差の修正をしているのであろう部分の $matches[4].$matches[5].$matches[6] ですが、 「:」を取る必要は無いような気がします。 -- [[henoheno]] &new{2005-06-04 (土) 22:20:32}; --コロンがあると、変換できませんけど。なので、現状のロジックなのだろうと思いました。-- [[upk]] &new{2005-06-05 (日) 00:18:42}; -確かにマニュアルのレベルでは冗長な処理のような気がします。とはいえGNUのマニュアルも含めた話であって、過去のPHPでもそうなのかが不明です。Debian Woodyあたりで動作を見るといいかもしれませんね -- [[henoheno]] &new{2005-06-04 (土) 22:21:54}; -「うまく機能していないような感じ」という件の概略(why)を教えて下さい。 -- [[henoheno]] &new{2005-06-05 (日) 00:05:06}; -この関数だけひっぱり出してデバッグしていたんですよ。取り出した $time を strtotime()で変換した値をもとに date()を使って、日付文字列にしていたんですが、おかしな日付となったんで、今回の差分を作って対応したわけです。しかし、ぱっと見のロジックだとおかしそうに無いんですよねぇ。環境依存なんですかね? -- [[upk]] &new{2005-06-05 (日) 00:18:42}; -- その時におかしくなった日付や、おかしくなかった日付は何ですか? (複数あれば、複数知りたいのですが) -- [[henoheno]] &new{2005-06-05 (日) 17:38:54}; --カレントデートでちょっとテストして、おかしかったので、デバッグをそれほどすることなく、修正しちゃったといったところです。まぁ、[[BugTrack2/76]]に絡んでの手当てでしたので、想定しない UTIMEが現状の値であり、それに加減算する値が共に同じだったことが幸いした。というところが、顕在化しなかったのかなぁ?と思っていますけど。-- [[upk]] &new{2005-06-07 (火) 01:20:57}; - [[BugTrack2/176]] -- &new{2010-08-16 (月) 21:43:51}; #comment
タイムスタンプを変更しない
RIGHT:&size(12){Category:[[:Plugin]]}; *showrss のタイムスタンプの処理が冗長 [#nb4b98b4] -ページ: [[BugTrack2]] -投稿者: [[upk]] -優先順位: 低 -状態: 提案 -カテゴリー: プラグイン -投稿日: 2005-06-04 (土) 21:49:54 -バージョン: **メッセージ [#u793c027] plugin_showrss_get_timestamp の処理において、タイムスタンプの処理が冗長になっていますので、strtotime() に任せるようにしました。 --- showrss.inc.php.ORG 2005-06-04 21:43:58.485997780 +0900 +++ showrss.inc.php 2005-06-04 21:45:16.359433684 +0900 @@ -298,12 +298,11 @@ $time = strtotime($str); return ($time == -1) ? UTIME : $time - LOCALZONE; } - $str = $matches[1]; - $time = strtotime($matches[1] . ' ' . $matches[2]); + $str = $matches[1] . ' ' . $matches[2]; if (! empty($matches[3])) { - $diff = ($matches[5] * 60 + $matches[6]) * 60; - $time += ($matches[4] == '-' ? $diff : -$diff); + $str .= ' ' . $matches[4].$matches[5].$matches[6]; } + $time = strtotime($str); return $time; } ?> ちょっとデバッグしていたんですが、従来のこの処理って、うまく機能していないような感じです。確認してみて下さい。とりあえず、冗長としておきますが。 ---- -お疲れ様です。とりあえず元のコードのempty()はisset()が適切なようで、if(preg_match)のブロックをくくり直した方が良さそうですね(でないとなぜ下の部分だけstrtotime()の返り値をチェックしていないのかがパッと見わからない)。また時差の修正をしているのであろう部分の $matches[4].$matches[5].$matches[6] ですが、 「:」を取る必要は無いような気がします。 -- [[henoheno]] &new{2005-06-04 (土) 22:20:32}; --コロンがあると、変換できませんけど。なので、現状のロジックなのだろうと思いました。-- [[upk]] &new{2005-06-05 (日) 00:18:42}; -確かにマニュアルのレベルでは冗長な処理のような気がします。とはいえGNUのマニュアルも含めた話であって、過去のPHPでもそうなのかが不明です。Debian Woodyあたりで動作を見るといいかもしれませんね -- [[henoheno]] &new{2005-06-04 (土) 22:21:54}; -「うまく機能していないような感じ」という件の概略(why)を教えて下さい。 -- [[henoheno]] &new{2005-06-05 (日) 00:05:06}; -この関数だけひっぱり出してデバッグしていたんですよ。取り出した $time を strtotime()で変換した値をもとに date()を使って、日付文字列にしていたんですが、おかしな日付となったんで、今回の差分を作って対応したわけです。しかし、ぱっと見のロジックだとおかしそうに無いんですよねぇ。環境依存なんですかね? -- [[upk]] &new{2005-06-05 (日) 00:18:42}; -- その時におかしくなった日付や、おかしくなかった日付は何ですか? (複数あれば、複数知りたいのですが) -- [[henoheno]] &new{2005-06-05 (日) 17:38:54}; --カレントデートでちょっとテストして、おかしかったので、デバッグをそれほどすることなく、修正しちゃったといったところです。まぁ、[[BugTrack2/76]]に絡んでの手当てでしたので、想定しない UTIMEが現状の値であり、それに加減算する値が共に同じだったことが幸いした。というところが、顕在化しなかったのかなぁ?と思っていますけど。-- [[upk]] &new{2005-06-07 (火) 01:20:57}; - [[BugTrack2/176]] -- &new{2010-08-16 (月) 21:43:51}; #comment
テキスト整形のルールを表示する