Timestamps, Data Vintages and Model Revisions

Name the different clocks

An economic observation can describe a month, be released weeks later and be revised again afterward. A model can consume that release, finish a calculation and publish a result at still later times. Give these events distinct field names. A generic date or as-of field is insufficient unless the specification defines precisely which event or period it represents and how the buyer should use it when reconstructing a decision.

Record buyer receipt separately from provider publication where possible. The provider may have made a result available before a network interruption prevented collection. Conversely, a local download timestamp may be much later than the information first became available. Neither timestamp alone describes the complete process. Ask which clocks are measured, which are inferred and which are unavailable, and preserve that uncertainty rather than manufacture apparent precision through a uniform timestamp display.

Use an explicit timestamp representation

RFC 3339 defines an Internet timestamp format with an explicit UTC marker or numeric offset. A timestamp such as 2026-10-05T14:02:00Z therefore communicates its offset in a way that a bare local time does not. Agree the required precision and parser behavior. A well-formed timestamp still needs a semantic definition: formatting cannot tell the buyer whether it records a source release, calculation completion or receipt by the consuming system.

For schedules tied to a local market, retain the applicable market calendar and time-zone rule in addition to individual timestamps. Daylight-saving changes and holidays can alter the relationship between local sessions and UTC. Avoid a fixed-offset shortcut for a location whose offset changes seasonally. When investigating short delays, identify clock-synchronization assumptions; subtracting two precise-looking timestamps does not establish precise latency if the underlying machines used unsynchronized clocks during the event being reviewed.

Preserve vintages instead of rewriting knowledge

The St. Louis Fed's real-time-period documentation distinguishes today's view of data from information known during an earlier period. That is a useful illustration of vintage-aware research. Its date-based interface should not be treated as proof of exact intraday availability. For a model using economic data, identify the source vintage and any additional release-time evidence needed for the proposed decision horizon, rather than assuming a historical observation date settles causal availability.

A correction changes the current best account of a value, but it does not change what a buyer previously received. Preserve both records where permissions and obligations allow, together with a revision identifier, reason and predecessor link. Keep input revisions distinct from model changes and delivery repairs. Reissuing an unchanged value after a transport failure is different from recalculating a value with corrected data or a newly calibrated model implementation.

Work through a hypothetical decision cutoff

Suppose a hypothetical observation refers to 14:00:00 UTC on an illustrative date. The first model output is published at 14:02:00 and received at 14:02:06. Observation-to-publication elapsed time is 120 seconds, publication-to-receipt is six seconds, and observation-to-receipt is 126 seconds. These are invented synchronized-clock inputs for a timing exercise, not a provider's measured latency or a promise that the model is suitable for a particular trading horizon.

A revised output is published at 14:10:00. For a reconstruction whose information cutoff is 14:05:00, the revised output is unavailable and the original received version is the relevant candidate, subject to all other eligibility rules. A current download containing only the revised value would not establish that earlier state. The buyer therefore requests revision identity and availability evidence before using the history for causal evaluation, while retaining the later correction for a separate current-view analysis.

Specify how corrections reach consumers

Ask whether corrections arrive as replacement snapshots, appended records or explicit change messages. Define a stable observation identity and a revision ordering rule so duplicate or late deliveries cannot silently restore an obsolete value. Preserve a distinction between the latest-view store and the authorized event history. The buyer should be able to answer both what is currently reported and what was received before a particular decision, without confusing one query with the other.

Test out-of-order delivery, repeated revisions, missing predecessors and corrections to identifiers as well as numerical values. A sequence number can help order changes, but its scope and reset behavior must be documented. Decide how a downstream report is marked when its source changes after publication. Do not silently replace the report and imply that recipients originally saw the corrected version. Keep the correction process proportionate to the significance and audience of the affected output.

Accept only the history the evidence supports

If a provider supplies only the latest corrected history, describe it that way. It may support current analysis or integration testing without supporting a point-in-time historical study. Do not invent old availability timestamps from file dates or marketing descriptions. Record the missing evidence and determine whether it blocks the specific procurement question. A limited dataset can still be useful when its limitations are explicit and the buyer's intended use does not require unavailable history.

Agree retention and access treatment for revision records through the actual licence and applicable jurisdiction-specific review. Detailed histories can be valuable evidence but may contain restricted data. Preserve only authorized material and enough metadata to explain the decision. A sound timestamp contract does not promise perfect foresight or immutable source data; it gives the buyer a reliable way to distinguish observations, deliveries and corrections, and to avoid attributing later knowledge to an earlier decision process.

• Separate timestamp syntax from event meaning.
• Keep latest values and as-known-at-the-time views distinguishable.

Source notes

1. RFC Editor: RFC 3339, Date and Time on the Internet
2. Federal Reserve Bank of St. Louis: FRED API Real-Time Periods