Metadata Time Travel¶
Metadata time travel allows you to query FMR as it existed at a specific point in time.
The idea is similar to temporal tables in relational databases and data warehousing platforms such as Microsoft Fabric Data Warehouse. In FMR, however, time travel applies to structural and referential metadata rather than to data rows.
This is useful when the current form of an artefact is not enough. For many operational and audit scenarios, you need to know what the artefact looked like when a dataset was created, validated, published, or reviewed.
Typical use cases include:
- validating each dataset against the structural metadata that was in force when it was created
- supporting audit, assurance, and compliance requirements
- investigating change histories and identifying when a specific update was introduced
FMR preserves historical metadata, allowing the full change history of each artefact to be traced. Metadata-driven processes can therefore be repeated against a stable historical view of the registry instead of being affected by whatever the current state happens to be.
Moreover, it preserves the meaning and validity of stored datasets by anchoring them to the structural and referential metadata that existed at a known point in time.
Semantic versioning provides a related but distinct benefit by making published artefact versions immutable. However, wildcard cross-references mean that structures such as DSDs are not always static in practice: they can evolve indirectly when referenced artefacts, such as Codelists, change. In these cases, metadata time travel can reproduce the resolved cross-reference graph exactly as it existed at a specific point in time.
Using metadata time travel¶
Metadata time travel is enabled by default. No special action is required when creating or maintaining structural metadata artefacts or reference metadata reports.
FMR automatically records changes made to every artefact and maintains a temporal record that can be used to reconstruct the state of the registry at a given time.
Time queries using the REST API¶
The following REST APIs support time travel:
- SDMX v2 Structure query
- SDMX v2 Reference Metadata query
- SDMX v2 Schema query
Historical metadata is queried using the asOf parameter.
The parameter value must be an ISO-8601 UTC date or date/time, as defined in FMR's Date and Time specification.
In summary:
- all times are interpreted as UTC, so
2026-04-18T12:39:00means 12:39 UTC, not local time - the
Zsuffix is optional and has no effect - time offsets from UTC are not supported and return an error; for example,
2026-04-18T12:39:00+05:30is not valid - if no time is specified, midnight UTC is assumed; for example,
2026-04-18means2026-04-18T00:00:00Z - if seconds are omitted, they default to
00; for example,12:39means12:39:00 - the time resolution is 1 second
Note
Querying the future is not supported.
If asOf is later than the current time, the query returns no results.
Examples¶
Get all Codelists as stubs, exactly as they were at 16:00 UTC on 12 April 2026:
https://example.registry.org/sdmx/v2/structure/codelist/*/*/~/?format=sdmx-3.0&detail=allstubs&asOf=2026-04-12T16:00:00Z
Get the complete structure graph as it was at 15:32 UTC on 23 June 2026:
Get the metadata report ABC:REPORT1(1.0) as it was at 09:00 UTC on 15 July 2026:
Get the schema in structure format for the ABC:MACRO_ECONOMICS(1.0) DSD as it was at 16:14 UTC on 23 April 2026: