記事を公開したあと、Qiitaの画面に表示された投稿日と、手元の運用記録の日付が違って見えることがあります。今回、公開操作をしたのは日本時間の2026年9月20日朝でしたが、記事ページの日付表示は9月19日でした。表示だけを見て公開日を転記すると、日次の記録がずれる可能性があります。

今回確認できた値

Vol.52「毎日投稿を止めたあと、手動公開をどう再開したか」について、Qiitaページでは投稿者が @boraemon2000、投稿日表示が「2026年09月19日」でした。一方、公開操作時のシステム時刻はUTCで 2026-09-19 22:11:40。日本時間（UTC+9）へ換算すると 2026-09-20 07:11:40 です。公開スケジュールにもJSTの日時として 2026-09-20T07:11:40+09:00 を記録しています。

この一例からQiita全体の日時仕様を断定することはできません。確認できたのは、同じ記事について画面の日付とJSTの記録日が異なって見えた、という事実です。

日付が食い違ったときの確認手順

公開URLと記事を特定する

タイトルだけで判断せず、公開ページのURLとitem_idを控えます。今回のitem_idは 197fe53347617c96ca84 でした。これで別記事や下書きの日時を見ている可能性を減らせます。
画面に出ている情報をそのまま記録する

Qiitaページの投稿日表示は「2026年09月19日」でした。まず表示値をそのまま残し、JSTの日付へ勝手に読み替えません。
操作時刻のタイムゾーンを確認する

操作時刻がUTCなら、JSTはUTCに9時間を加えます。今回の 2026-09-19 22:11:40 UTC は、日付をまたいで 2026-09-20 07:11:40 JST です。時刻だけでなく、日付境界を越えたかも確認します。
目的に合わせて記録欄を分ける

公開スケジュールの published_at は、今回の運用ではJSTのISO 8601形式とし、画面表示についてはnotesへ別記しました。例は 2026-09-20T07:11:40+09:00 です。画面の日付を保存する欄が別にあるなら、そこには表示どおりの日付を記録します。

避けたい判断

画面の日付と手元の日時が違うからといって、すぐに公開失敗や二重投稿と判断しないことが大切です。逆に、時差だろうと決めつけて確認を省くのも危険です。URL、item_id、投稿者、公開ページの状態を先に確かめ、必要ならUTCとJSTの両方を残します。

また、タイムゾーンが分からないログを見た目だけで変換してはいけません。元の時刻がUTCなのか、ローカル時刻なのかを確認できない場合は、未確定としてそのまま記録します。後から説明できるよう、元の値と変換後の値を両方残すのが安全です。

まとめ

日付が食い違ったときは、画面表示と運用上の時刻を一つの値に無理にそろえず、何を示す値かを分けて記録します。公開URLとitem_idで対象を特定し、元のタイムゾーンを確認してから変換する。これだけで、翌日の重複判定や公開履歴の引き継ぎを誤りにくくなります。