Name the clock you are showing
When presenting historical Reddit discussions within your application, the most critical challenge is clarifying which timestamp defines the result’s age. A source creation time, the moment your app fetched a record and the moment an archive ingested it answer different questions. Do not label them all Updated. A request made today can retrieve an old discussion without making its contents current.
For the hypothetical hiking feature, a walker comparing offline-map advice needs to know that a reference is historical. If a valid created_utc value is present, label the displayed date as the source post or comment’s creation date. The API passes through flat source records; do not assume every record includes that field or that its value is valid for display.
Give missing dates a real design state
Consider two proposed card labels, not retrieved examples: Original date: available from the record, and Original date: unavailable. The second card should still be readable without silently substituting today’s date. A missing timestamp is missing evidence, not evidence that the discussion is new.
Validate the field’s type and range before formatting it. For a relative label such as years ago, make its basis clear and provide an understandable absolute date where possible. Account for the app’s display timezone. If the client clock is wrong or the value cannot be interpreted confidently, use a conservative missing-date state rather than a precise but unreliable age.
Keep retrieval history separate
Your app may record when it fetched or saved an item to explain the state of its local reading list. Label that value Fetched by this app or Saved locally. It describes the app’s action, not the record’s creation, last edit, last reply, ingestion time or present accuracy. It is also not a latency measurement by itself.
Do not manufacture an archive ingestion date from the request time. The current interface does not promise such a timestamp for each record. Nor should you infer a complete archive coverage period from the oldest or newest item in a small response. The absence of a result can have several explanations and does not prove that the discussion never existed.
Filter dates without claiming a timeline
Date filtering narrows the scope of your search but does not provide chronological sorting. from and to accept YYYY-MM-DD dates in UTC, with the to day included. A hypothetical request for from=2025-01-01 and to=2025-12-31 asks for that source-date range; it does not ask for the newest result first.
The service returns archive _doc order. If your app sorts the fetched records locally by a valid creation field, describe the result as a sort of those loaded records. It cannot establish that the first card is the newest match anywhere in the archive. Records missing a usable date need a separate, explained placement rather than an invented timestamp.
Bring the date back to the reader’s decision
An old discussion might help the walker decide which offline-map questions to investigate: download preparation, battery use or the limits of a device. It cannot establish that a route is open, that a product behaves the same today or that a past workaround remains appropriate. Keep the reading feature distinct from navigation and current safety information.
A calm historical label is more useful than an unsupported freshness badge. Avoid Recently active, Fully synced or Live advice unless you have separate evidence for the specific claim; this archive response does not provide it. Keep source links when available, and handle a source page that has changed or disappeared. Return to /en/#field-notes for discussion-card and local-reading-list design.
