govstack-cfr-data#req-2 requires "ISO 8601 in UTC" for all timestamps. ISO 8601 is a large
family of formats, most of which JSON tooling rejects. The tight profile that every JSON API
actually implements is RFC 3339. Recommending the correction now, while it is still cheap.
Current text
spec/6-cross-functional-requirements/6.6-data.md, #2 Use ISO 8601/UTC for timestamps (REQUIRED IMMUTABLE OBSERVABLE):
All timestamps follow ISO 8601 in UTC (e.g., 2025-11-12T13:30:00Z).
Why this is a problem
ISO 8601 permits, and a conformance test written against it must accept:
- basic format without separators:
20251112T133000Z
- ordinal dates:
2025-316T13:30:00Z
- week dates:
2025-W46-3T13:30:00Z
- reduced precision:
2025-11, 2025
None of these are accepted by standard JSON Schema date-time validation, and none are
produced or parsed by mainstream API tooling. So an implementation could be strictly conformant
to #req-2 as written and still be unconsumable by every other Building Block. The example
given in the requirement (2025-11-12T13:30:00Z) is in fact an RFC 3339 timestamp, so the
intent is already RFC 3339; only the citation is wrong.
Two secondary points:
- RFC 3339 is freely readable. ISO 8601 is
paywalled by ISO, which is a poor fit for a REQUIRED requirement in an ecosystem intended for
open adoption by government teams and vendors of any size.
- JSON Schema's
date-time format is defined against RFC 3339, so citing RFC 3339 makes the requirement
machine-checkable with no extra work.
Proposed change
All timestamps follow RFC 3339 (the interoperable profile of ISO 8601) with the Z UTC
designator (e.g., 2025-11-12T13:30:00Z).
The rest of the requirement text is unaffected. The UTC-only constraint should stay: it is
stricter than RFC 3339, which permits arbitrary offsets, and it is the right call for
cross-border exchange.
Why now
#req-2 is classified IMMUTABLE, so under
spec/5-specification-framework/5.2-specification-model.md it cannot be altered by an extending
specification. Every Building Block specification that adopts the current wording inherits it
unchangeably, which makes this more expensive to correct with each adoption.
This is a correction to a reference to an external standard rather than a change in required
behaviour: no implementation that is conformant today becomes non-conformant, because every
RFC 3339 timestamp is a valid ISO 8601 timestamp.
govstack-cfr-data#req-2requires "ISO 8601 in UTC" for all timestamps. ISO 8601 is a largefamily of formats, most of which JSON tooling rejects. The tight profile that every JSON API
actually implements is RFC 3339. Recommending the correction now, while it is still cheap.
Current text
spec/6-cross-functional-requirements/6.6-data.md,#2 Use ISO 8601/UTC for timestamps (REQUIRED IMMUTABLE OBSERVABLE):Why this is a problem
ISO 8601 permits, and a conformance test written against it must accept:
20251112T133000Z2025-316T13:30:00Z2025-W46-3T13:30:00Z2025-11,2025None of these are accepted by standard JSON Schema
date-timevalidation, and none areproduced or parsed by mainstream API tooling. So an implementation could be strictly conformant
to
#req-2as written and still be unconsumable by every other Building Block. The examplegiven in the requirement (
2025-11-12T13:30:00Z) is in fact an RFC 3339 timestamp, so theintent is already RFC 3339; only the citation is wrong.
Two secondary points:
paywalled by ISO, which is a poor fit for a REQUIRED requirement in an ecosystem intended for
open adoption by government teams and vendors of any size.
date-timeformat is defined against RFC 3339, so citing RFC 3339 makes the requirementmachine-checkable with no extra work.
Proposed change
The rest of the requirement text is unaffected. The UTC-only constraint should stay: it is
stricter than RFC 3339, which permits arbitrary offsets, and it is the right call for
cross-border exchange.
Why now
#req-2is classified IMMUTABLE, so underspec/5-specification-framework/5.2-specification-model.mdit cannot be altered by an extendingspecification. Every Building Block specification that adopts the current wording inherits it
unchangeably, which makes this more expensive to correct with each adoption.
This is a correction to a reference to an external standard rather than a change in required
behaviour: no implementation that is conformant today becomes non-conformant, because every
RFC 3339 timestamp is a valid ISO 8601 timestamp.