News feeds appear to offer an obvious order: the newest item comes first. That order becomes less obvious when a publisher revises an article, an aggregator retrieves it late or two timestamps use different offsets. A displayed date can also refer to a described event rather than the document itself. This guide builds a practical method for comparing those clocks. All example times and sequences are invented exercises, not historical publication claims. The aim is to keep time useful as evidence without allowing a convenient timestamp to establish more about an event, source or version than its actual meaning supports.
Name the event before interpreting the time
A timestamp should answer when something specific happened. Publication time concerns the release of a document or item; update time concerns a change to it; retrieval time records when a system obtained it. Event time concerns the activity described in the report. A single article can legitimately have all four, and they need not be close together. Begin a record with separate fields rather than choosing whichever value makes the item look freshest. If the source does not establish what a date means, preserve its label and the uncertainty instead of silently assigning it a stronger interpretation.
In an invented example, a report published on Friday describes a network event from Wednesday and is retrieved on Saturday. An aggregator that labels Saturday as the article's publication date has changed the history rather than merely changing its display. A later correction on Sunday adds another event, not a reason to erase Friday's original role. This distinction is especially important in an archive, where the date a page was saved can be mistaken for when it first appeared. A capture establishes a saved version, not the whole preceding publication timeline.
Normalise offsets before sorting instants
RFC 3339 defines a timestamp format with explicit date, time and offset information. A numerical offset lets a reader relate a local representation to UTC. In a fictional comparison, 10:00 at an offset of plus two hours represents 08:00 UTC, while 08:30 UTC is half an hour later. Sorting the displayed hour fields alone would reverse that order. Convert complete, valid timestamps to a common basis for comparison while retaining the original representation. The conversion should make the relationship clearer, not destroy the information about how the source expressed the time.
Do not assume an offset from a publisher's country or the reader's own device. A publication can use UTC, a regional convention or another stated system regardless of where its organisation is based. Daylight-saving rules also mean a regional time zone is not always the same thing as one fixed numerical offset. For an ordinary feed reader, the practical requirement is to know whether the source supplied a definite instant. If only a date is given, adding midnight in the reader's time zone creates precision that was not present in the original record.
Distinguish unknown time from a convenient default
Missing or ambiguous time information should remain visible as such. A system can store a null value, an unparsed original label and a reason why it could not establish an instant. Replacing every missing time with the import time makes the collection look complete while corrupting chronological comparisons. Replacing it with zero creates another misleading order. Choose a display policy that treats unknown publication time explicitly, such as a separate undated group or a clearly labelled retrieval-order view. The policy should not pretend that every item carries an equally precise publication timestamp.
A fictional feed contains an item with a date but no time and another with a complete timestamp from that same day. You cannot know their within-day order from those fields alone. It may still be useful to show them together, but explain the sorting basis. The same caution applies to human-readable labels such as yesterday when the page's reference time is not preserved. Those labels can be meaningful in a live interface yet become ambiguous in a saved document. Keep the captured wording without converting it into a guessed absolute timestamp unless additional evidence supports that conversion.
A changed update time does not necessarily mean a new event
Feed formats distinguish item identity and time-related metadata in ways that help a reader process revisions. Atom, for example, has separate published and updated elements with defined meanings. A later update can be a substantive correction, a new section or another change recognised by the publisher. It does not automatically mean the underlying event happened again. A useful reader keeps the same item connected to its revision history rather than creating a fresh independent story every time one field changes. The publisher's identity convention and actual content change both matter.
Consider an invented report about a planned upgrade. Its update time changes after the author corrects a date. Treating the revised item as a new announcement could make a timeline appear to contain two separate plans. The opposite error is ignoring every update and leaving an important correction invisible. Compare the changed fields and preserve the relationship between versions. The summary can say that the source revised its schedule statement without claiming that the upgrade itself occurred. Chronology is most informative when it tracks documents and events at their own levels instead of collapsing them into one stream.
Measure delay with the right pair of clocks
The difference between retrieval time and a source timestamp can suggest a delay, but its interpretation depends on both clocks being reliable and on the timestamp's meaning. A feed can republish an old item, a server can cache a representation and an aggregator can poll infrequently. A negative apparent delay may indicate a clock or parsing problem rather than information arriving before it existed. Record the observation and investigate the assumptions. A neat subtraction is not automatically a measurement of publication latency if one endpoint describes an update and the other describes a different version's retrieval.
In a deliberately invented exercise, a source item says 12:00 UTC and a reader retrieves it at 12:08 UTC. Eight minutes is the difference between the stated times, not proof that the aggregator waited exactly eight minutes after first publication. The item may have been available earlier under another version or delayed by an upstream cache. The narrower statement is more defensible: this representation was retrieved eight minutes after its stated timestamp. If the task requires a stronger latency claim, additional observations about polling, caching and source availability are needed rather than a more confident label on the same subtraction.
Build a timeline that survives later inspection
Keep original timestamp strings, parsed values, the field they came from and the retrieval context. Display the chosen chronological basis clearly: published order, updated order or retrieval order. When an item lacks a trustworthy value for that basis, apply a defined fallback and label it rather than disguising the fallback as publication history. Preserve the version used for an interpretation where feasible. These small choices make a feed useful beyond the moment it is displayed, especially when someone later asks why an item appeared before another or which source version a summary referred to.
The historical catalogue on this site separates archive capture identifiers from any printed source labels. New essays and annotations have their own actual publication dates. That separation prevents restoration work from turning the age of a source into a false date for newly written material. A useful feed is not merely a list sorted by numbers. It is a chronology of named events and documents whose timestamps have understandable meanings. Identify the clock, normalise only what can legitimately be normalised and retain uncertainty where the source has not supplied enough information to order the record more precisely.
Sources & further reading
Primary documentation informs the definitions. The worked scenarios and explanations are newly written; hypothetical examples are not historical events.