Data Freshness & Revisions

Understanding how Snowtrail handles data updates and revisions.

Update Schedules

Product	Update Frequency	Trigger	Typical Time (UTC)
GBSI-US	Weekly	Thursday EIA storage release	14:30
GBSI-EU	Daily	GIE AGSI daily publication	17:00
GLMI	Monthly (fundamentals) / Daily (price)	IEA trade flow data / daily price feeds	08:00
PEMI	Daily	Nord Pool UMM aggregation	07:00
WRSI	4x daily	NOAA model runs (00Z, 06Z, 12Z, 18Z)	05:00, 11:00, 17:00, 23:00
WSSI-US	4x daily	NOAA model runs (00Z, 06Z, 12Z, 18Z)	05:00, 11:00, 17:00, 23:00

Revisions

When a source restates a value we have already published, our next scheduled run picks it up and the affected rows are recomputed. The derived layers are bitemporal: the recomputed row is appended as a new version rather than overwriting the old one, and each version carries its own str_observed_at.

This means:

1. A plain query returns the current best value, so restatements flow through automatically
2. as_of returns the value you would have acted on, not today's restated figure. If a series was published at 100 and later restated to 105, an as_of preceding the restatement returns 100
3. Only genuine changes are stored. A recomputation that reproduces the same value adds no version, so the history records revisions rather than pipeline runs

Two limits are worth knowing. Reconstruction cannot reach back before raw object versioning began, which is 2026-01-13 for GBSI-EU and WRSI and 2026-03-02 for the other four products; an earlier as_of returns the oldest state we can prove rather than erroring. And as_of reconstructs data, not models: it returns what the current model computes from the data knowable at the time, and does not resurrect a past model version.

from snowtrail import Snowtrail
client = Snowtrail(api_key="your-api-key")

# Point-in-time query: returns only data that had become knowable by the as_of date
df = client.gbsi_us.system_stress(
    date_from="2024-01-01",
    date_to="2024-06-30",
    as_of="2024-03-15"
)