A source can announce a change on one day, describe an event from another day, and be checked by an editor months later. The article's publication and modification dates describe the publication's own work. Keep these dates separate.
This distinction matters when a high-volume publication reviews documentation. Checking an old announcement today does not make the underlying event new. A source review can be useful, but its label should tell the reader what was actually refreshed.
The timeline below is hypothetical. It illustrates an editorial data model rather than a real product launch.
Map a source review accurately
| Date field | Invented example | Meaning |
|---|---|---|
| Event date | May 1 | The feature became available to the stated audience |
| Announcement date | May 2 | The company published its announcement |
| Source checked | September 9 | The editor inspected the source |
| Article published | September 9 | The publication released its own analysis |
| Article modified | Only when substantive work occurs | A later revision to the publication's article |
A headline such as “Company launches feature today” would be inaccurate for the September review. A source-check label and a paragraph preserving the May event date can communicate the useful current analysis without inventing a new announcement.
Preserve the precision you actually know
If a source provides only a month, record the month. Do not choose the first day or a convenient midnight timestamp and present it as observed fact. If the event date is not stated, mark it unknown rather than borrowing the announcement date automatically.
Record time zones when actual times matter. A release near midnight can fall on different calendar dates for different audiences. Use a consistent display policy and preserve the original source timestamp where available.
Keep estimated or inferred dates labeled as such. An archive URL containing a year is not always proof of the exact publication date.
Handle machine-readable outputs deliberately
Page metadata, structured data, feeds, and sitemaps may consume the same editorial record in different formats. Do not let a formatting helper silently invent precision that the source lacks.
The RSS 2.0 specification, checked September 9, 2026, makes an item's pubDate optional and defines its date-time format. If a publisher has only a date and chooses not to assert a time, omitting that optional field can be more accurate than manufacturing a midnight event.
Keep the visible article date, metadata, and revision record consistent about what they represent. A build timestamp belongs to the deployment record unless it is also the actual documented publication time.
Review dates as part of the claim check
For every news brief, ask whether the source describes a launch, an expansion, a preview, a documentation revision, or an older event being revisited. Put the relevant condition and date near the factual claim.
Check relative language such as today, yesterday, now, and recently. Those words can become misleading when an article is reused or updated. Concrete dates often travel more accurately across archives and excerpts.
Use the recency review to decide whether the source merits new coverage. A publication can produce timely, useful analysis while preserving the chronology of what actually happened.