States the run timestamp in UTC, whatever zone it ran in
All 4 scenarios hold
A report states the timestamp in UTC, whatever zone the build ran in. A report generated in CI then reads the same for every reader. The label a reader sees drops the sub-second precision nobody needs. The attribute beside it holds whole seconds, so a tool can compare the report against the revision it came from.
A report reads the clock unless the build pins an instant. A build that pins one gets the same bytes from the same tests, which is what a build comparing two runs needs. The rows below read reports the build pinned.
expected outcome
broken scenario
| Scenario | Instant the build pinned | Timestamp attribute? | Footer label? |
|---|---|---|---|
| Afternoon run | 2026-07-20T14:32:09Z | 2026-07-20T14:32:09Z | 20 Jul 2026 14:32 UTC |
| The same instant, CEST | 2026-07-20T16:32:09+02:00 | 2026-07-20T14:32:09Z | 20 Jul 2026 14:32 UTC |
| Sub-second precision | 2026-07-20T14:32:09.123456Z | 2026-07-20T14:32:09Z | 20 Jul 2026 14:32 UTC |
| Turn of the year | 2027-01-01T00:00:00Z | 2027-01-01T00:00:00Z | 1 Jan 2027 00:00 UTC |