어느 시점을 표시하는지 이름을 붙이세요
앱에서 과거 Reddit 토론을 표시할 때 가장 중요한 과제는 결과의 오래된 정도를 어느 타임스탬프로 정의하는지 분명히 하는 것입니다. 원문의 작성 시점, 앱이 레코드를 조회한 시점, 아카이브에 수집된 시점은 서로 다른 질문에 답합니다. 모두 「업데이트됨」으로 표시하지 마세요. 오늘 보낸 요청으로 오래된 토론을 조회했다고 해서 그 내용이 최신이 되지는 않습니다.
가상의 하이킹 기능에서 오프라인 지도 조언을 비교하는 사람은 참고 자료가 과거의 것임을 알아야 합니다. 유효한 created_utc가 있으면 표시 날짜가 원본 게시물 또는 댓글의 작성일임을 알리세요. API는 평면 원본 레코드를 전달하므로 모든 레코드에 그 필드가 있거나 표시할 수 있는 값이라고 가정하지 마세요.
날짜 없음도 실제 설계 상태로 다루세요
조회한 예시가 아니라 제안하는 카드 라벨 두 개를 생각해 보세요. 「원본 날짜: 레코드에서 확인 가능」과 「원본 날짜: 확인 불가」입니다. 두 번째 카드도 오늘 날짜로 몰래 대체하지 않고 읽을 수 있어야 합니다. 타임스탬프가 없는 것은 근거가 없다는 뜻이지 새 토론이라는 근거가 아닙니다.
형식을 지정하기 전에 필드의 타입과 범위를 검증하세요. 「몇 년 전」 같은 상대 표시에는 기준을 분명히 하고, 가능하면 이해할 수 있는 절대 날짜를 함께 제공합니다. 앱의 표시 시간대도 고려하세요. 클라이언트 시계가 잘못되었거나 값을 자신 있게 해석할 수 없다면, 정밀해 보이지만 신뢰할 수 없는 경과 시간보다 보수적인 날짜 없음 상태를 사용하세요.
조회 이력은 분리하세요
기기 내 읽기 목록 상태를 설명하기 위해 앱이 항목을 조회하거나 저장한 시점을 기록할 수 있습니다. 그 값에는 「이 앱에서 조회함」 또는 「기기에 저장함」이라고 표시하세요. 이는 앱의 동작이지 레코드 작성, 마지막 편집, 마지막 댓글, 수집 시각 또는 현재 정확성을 설명하지 않습니다. 그 값 하나만으로 지연 시간을 측정한 것도 아닙니다.
요청 시각을 아카이브 수집 시각으로 만들어 쓰지 마세요. 현재 인터페이스는 각 레코드에 그런 타임스탬프가 있다고 약속하지 않습니다. 작은 응답의 가장 오래되거나 가장 최근인 항목만으로 전체 아카이브 수록 기간을 추론해서도 안 됩니다. 결과가 없는 데에는 여러 이유가 있을 수 있으며 토론이 한 번도 존재하지 않았다는 증거는 아닙니다.
날짜를 필터링하되 시간순이라고 주장하지 마세요
날짜 필터는 검색 범위를 줄이지만 시간순 정렬을 제공하지 않습니다. from과 to는 UTC의 YYYY-MM-DD 날짜를 받고 to 날짜도 포함합니다. 가상의 from=2025-01-01, to=2025-12-31 요청은 그 원본 날짜 범위를 요구하는 것이지 최신 결과를 먼저 달라는 요청이 아닙니다.
서비스는 아카이브 _doc 순서로 반환합니다. 앱이 조회한 레코드를 유효한 작성 필드로 로컬 정렬한다면, 로드된 레코드만 정렬한 결과라고 설명하세요. 첫 카드가 아카이브 전체에서 가장 최근인 일치라고 확정할 수는 없습니다. 사용 가능한 날짜가 없는 레코드는 타임스탬프를 지어내는 대신 별도의 배치 규칙을 정하고 설명해야 합니다.
날짜를 독자의 판단과 연결하세요
오래된 토론은 사용자가 사전 다운로드, 배터리 사용량, 기기 한계 등 오프라인 지도에서 무엇을 알아볼지 정하는 데 도움이 될 수 있습니다. 경로가 열려 있다거나 제품이 지금도 같은 방식으로 작동한다거나 과거의 우회 방법이 여전히 적절하다는 사실은 입증하지 못합니다. 읽기 기능은 길 안내 및 현재 안전 정보와 분리하세요.
차분한 과거 자료 표시가 근거 없는 최신성 배지보다 유용합니다. 별도의 구체적 증거가 없다면 「최근 활동」, 「완전히 동기화됨」, 「실시간 조언」 같은 표현을 피하세요. 이 아카이브 응답은 그 증거를 제공하지 않습니다. 출처 링크가 있으면 보존하고, 원문 페이지가 바뀌거나 사라졌을 때도 처리하세요. 토론 카드와 기기 내 읽기 목록 설계는 /ko/#field-notes에서 확인할 수 있습니다.
