正しい更新日時を拾わせるためには

なつみかんの更新日時調査の原理と手順

なつみかんは、だいたい次のような動作原理でチェック対象ページの更新日時を調べます。

まず「 HTTP ヘッダ」の「 Last-Modified フィールド」を見るです。これが通称「 HEAD 取得 」。 HTTP ヘッダだけ見てる段階では、実際にページ内容そのものを取り寄せているわけではないです。（「なつみかん」でできることの項を参照。） HEAD 取得なら、アンテナ側も被捕捉側も負荷が最小で済みます。
HTTP ヘッダの Last-Modified が出てなかったバヤイは、実データ（ HTML ソース）を取り寄せます。これが通称「 GET 取得 」。 HTML ソース中に更新日時とおぼわしきモノがあれば、それを使います。なつみかんはなかなかアタマが良くて、なにも設定しなくても自動的にそれを見つけてくるのですが、ときどき全然関係ないモノに反応してワケワカな日時を拾ったりします。
GET 取得で自動的に正しい日時が拾えない場合、HTML ソース中で更新日時が書かれている部分がどこなのかを、アンテナ管理者が手動で指示します。目印の語句を指定するとか、正規表現とか使って。この場合、更新日時が日付までしか書かれていなくて時刻までは不明の場合、その日の午前 0 時ちょうどの更新とゆー扱いにされちゃいます。
ここまででダメな場合、ファイルサイズ（というか、正確には送られてくる実データの量）の変動を感知して、変化があった場合はその時刻を更新日時とします。なつみかんの仕様では、この時の記録はだいたい 3 時間で抹殺されて、更新日時不明となってリストの一番下までブッ飛びます。ただし「さとみかん」ではその処理部分を改造してあるので、何時間経っても更新時刻情報は消えません。
または、別ファイル（別 URL ）をチェック対象とすることも可能です。動的生成ページの元データのテキストファイルとか。昨今ハヤリのブログ系サイトならば、たいてい自動で生成されてる RSS とか。静的な (実体が存在する) ファイルならたいてい、何もせずとも Last-Modified が出てるはずなので。もしくは、更新日時の Last-Modified を返すだけの CGI とかって手もアリ。
以上でダメなら、取得失敗としてジエンド。

正しい更新日時が拾われない場合の対処

更新日時がなんだか正常に取得されていないと感じた場合は、以下の手順を試してみてください。

Web サーバがどんな HTTP ヘッダを出してるのかを見るには、まぁいろんなやりかたがありますけど、View HTTP Request and Response Header に掛けるという手もあるです。これの結果表示のアタマのほうに、送出された HTTP ヘッダがいろいろ書かれてるです。これの Last-Modified: のトコロの時刻が正しいかどうか見る。おかしいなら、サーバ管理者に連絡とかしてみる。
SSI でなにか細工してるページでは通常、 Last-Modified は出ません。無料サーバとかで広告が入るところなんかでも、そういうケースがままあります。サーバが Apache なら、 .htaccess に XBitHack full と書いて、アンテナから捕捉されてるファイルに実行権限を付ければ、うまくいくかもしれません。
CGI 仕掛けで動的生成してる場合なども、なにも考慮してなければ当然 Last-Modified は出ません。適切な Last-Modified ヘッダを出すようにしてくれればオールオッケー。
以上の手段が使えないのであれば、更新日時を手動や自動（ SSI など）で HTML 実ソース中に書いておくのが手です。なるべくソースの先頭のほうに書いて、しかも日付だけじゃなくて時刻まであるとウレシー。書式は "2002/04/05 16:40" とか "Fri, 05 Apr 2002 16:14:02 JST" とかで OK 。なつみかんはアタマがいいから。もしだめなら、日時を書いておく位置を変えるとか、日時書式をいろいろ変えてみる方向で。 WWWC 用 META タグやちえりリスト用の META タグがあれば話は早いです。
更新日時取得用の別リソースを用意する。調査対象ページが動的生成されているばあい、その元データであるテキストファイルがあるなら、それが使えます。昨今ハヤリのブログ系サイトならば、 RSS がたいてい自動で生成されてるので話が早い。静的な (実体が存在する) ファイルならたいてい、何もせずとも Last-Modified が出てるはず。もしくは、 Last-Modified を返すだけの CGI を用意するとか。そのようなモノがあるばあい、所在をアンテナ管理者（つまりぼく）に教えてみる。
アンテナから外すように苦情を言う（笑）

よくわからなければ、メール等さまざまな方法でご相談ください。

リダイレクトにまつわるよくあるミス

「さとみかん」は、捕捉先の URI が別 URI へのリダイレクトになっている場合も、そのリダイレクトを追跡して更新日時を問題なく取得できます。ただし、以下のようなケースではリダイレクトを追跡しないので、更新日時を正常取得できません。

`Location` フィールドが絶対 URI で示されていない

HTTP 応答ヘッダの Location フィールドの値は、必ず「絶対 URI (absolute URI) をひとつだけ」でないとダメです。相対パスで示されている場合は無視します（リダイレクトを追跡しません）。

リダイレクト時のステータスコードが "301 Moved Permanently" である

「さとみかん」は、ステータス 301 のリダイレクトを追跡しません。ステータス 302 のリダイレクトのみを追跡します。

ステータス 301 は、元の URI にあったリソースがリダイレクト先 URI へ恒久的に移動したことを示します。時の流れあるいはログの蓄積に従って最新記事ページ（実体）の URI が次々変わってゆくなかで、「最新記事ページの URI 」を擬似的に固定するためにリダイレクトを使っている場合（その例）、その用途に相応しいステータスコードは 302 です。

301 Moved Permanently: リクエストされたリソースは新しい恒久的な URI に割り当てられたので、以降そのリソースへの参照は返された URI の一つを使用すべきである。リンク編集機能を持つクライアントは、可能であればサーバにより返された新しい参照の一つ以上の Request-URI を参照するように自動的に再リンクすべきである。
302 Found: リクエストされたリソースは、一時的に別の URI に属している。このリダイレクションは場合によって変更されるかもしれないので、クライアントは将来のリクエストではその Request-URI を使い続けるべきである。

HTML の META refresh でリダイレクトさせようとしている

「さとみかん」は、HTML ソースに書き込まれた <meta http-equiv="refresh" content="..."> を解釈しません。