どの時点を表示しているのか明記する
過去のRedditの議論をアプリで示すとき、重要なのは、どのタイムスタンプで結果の古さを表すかを明らかにすることです。出典の作成時点、アプリがレコードを取得した時点、アーカイブが取り込んだ時点は、別々の問いに答えます。すべてを「更新日」と表示しないでください。今日のリクエストで古い議論を取得しても、その内容が最新になるわけではありません。
仮想のハイキング機能でオフライン地図の助言を比べる利用者には、過去の参照資料であると分かる必要があります。有効なcreated_utcがあれば、表示する日付を元の投稿またはコメントの作成日と示してください。APIは平坦なソースレコードをそのまま返します。すべてのレコードにこのフィールドがあり、表示できる値が入っているとは考えないでください。
日付がない場合も正式な表示状態にする
取得した例ではなく、カードの表示案として「元の日時：レコードから確認可能」と「元の日時：不明」を考えます。後者でも、今日の日付に黙って差し替えず、内容を読めるようにします。タイムスタンプがないのは証拠が欠けている状態であり、議論が新しい証拠ではありません。
書式を整える前にフィールドの型と値の範囲を検証してください。「何年前」のような相対表示では根拠を明確にし、可能なら分かりやすい絶対日付も示します。アプリの表示タイムゾーンも考慮してください。クライアントの時計が誤っている場合や、値を確信して解釈できない場合は、精密だが信頼できない経過時間を示すより、控えめに日付不明として扱います。
取得した履歴は別に残す
端末内の閲覧リストの状態を説明するため、アプリが取得日時や保存日時を記録することはできます。その値には「このアプリで取得」「端末に保存」などのラベルを付けます。示しているのはアプリの操作であり、元レコードの作成、最終編集、最後の返信、取り込み時点、現在の正確性ではありません。それだけで遅延を測定したことにもなりません。
リクエスト時刻からアーカイブへの取り込み日時を作り出してはいけません。現在のインターフェースは、各レコードにその時刻があるとは約束していません。また、小さなレスポンスの最古または最新のレコードから、完全な収録期間を推測してはいけません。結果がない理由は複数考えられ、その議論が一度も存在しなかった証拠にはなりません。
日付を絞っても時系列とは主張しない
日付フィルターは検索範囲を絞りますが、時系列に並べ替えるものではありません。fromとtoはUTCのYYYY-MM-DD形式の日付を受け付け、toの日も含みます。仮にfrom=2025-01-01とto=2025-12-31を指定すると、その出典日付の範囲を要求するのであり、最新の結果を先頭にする要求ではありません。
サービスはアーカイブの_doc順で返します。取得したレコードをアプリ内で有効な作成日時によって並べ替えたら、読み込み済みのレコードを並べ替えたものだと説明してください。先頭カードがアーカイブ内の全一致の中で最新だとは示せません。利用できる日付がないレコードは、時刻を作るのではなく、配置方法を別に決めて説明する必要があります。
日付を読み手の判断につなげる
古い議論は、事前ダウンロード、電池の消費、端末の制約など、オフライン地図について何を調べるかを決める助けになります。ただし、ルートが通行可能なこと、製品が今も同じように動くこと、過去の回避策が今も適切なことは示せません。閲覧機能を、ナビゲーションや現在の安全情報から分けてください。
根拠のない鮮度バッジより、落ち着いた過去資料の表示の方が役立ちます。「最近も活動中」「完全に同期済み」「リアルタイムの助言」は、その主張を裏付ける別の証拠がない限り避けてください。このアーカイブレスポンスからは得られません。出典リンクがあれば保持し、リンク先が変わった場合やなくなった場合にも対応します。議論カードと端末内の閲覧リストの設計は/ja/#field-notesを参照してください。
