# What invariants prevent naive ISO8601 timestamps from shifting the event instant?

**Date of Record:** 2026 November 2

**Scope:** Applies to timestamps serialized as ISO8601 without a trailing Z or ±HH:MM offset, at a boundary where producer and consumer may disagree on interpretation. Does not apply to timestamps carrying an explicit offset, or systems with a global TZ discipline enforced by schema.

## Core Distinction

An ISO8601 timestamp without a timezone is *local* by definition, but most consumers assume UTC. When producer and consumer disagree, the same string names two instants differing by the offset between producer locale and UTC.

**Invariant.** The instant is unambiguous if and only if every timestamp on the path carries Z or ±HH:MM, or producer and consumer are documented, enforced, and tested to interpret naive as the same zone.

**Violation.** A service in UTC-8 emits `2026-11-02T09:00:00`. A consumer in UTC parses it as 09:00 UTC. The event at 17:00 UTC is recorded as 09:00 UTC — an eight-hour shift, silently, with a direction that changes with DST.

**Asymmetry.** Both serializations are valid ISO8601; both parsers behave as documented. The shift exists only in the relationship between them.

## What Was Observed

**Signature.** Events clustered at an offset boundary. Nightly batches whose window no longer matches expected traffic. Timestamps appearing off by hours only for records from a specific source.

**Trace.** Producer in UTC-8, serialization omits offset, consumer in UTC. Timestamp `2026-11-02T09:00:00` becomes 2026-11-02T09:00:00Z, but the producer meant 2026-11-02T17:00:00Z. Every event from that source shifts by eight hours, and by nine when DST is active.

**Why monitoring stays green.** Both sides validate their own format. Timestamps are well-formed. Lag and throughput do not look wrong unless compared against a source of truth.

## Condition of Validity

The instance must ensure at least one holds before it treats a naive timestamp as a point in time:

1. **Must carry offset.** Every timestamp carries Z or ±HH:MM, and the schema enforces it.
2. **Must document naive-means-UTC.** Both producer and consumer are documented, enforced, and tested to interpret naive as the same zone, including during DST changes.
3. **Must parse into a typed value.** Timestamps are parsed into a type that refuses to construct without a timezone.

Condition 1 is structural; 2 and 3 are compensations. The instance must know which applies before it compares two timestamps as points in time.

## Decision Boundary

- Offset present on every timestamp: unambiguous.
- Naive with global TZ discipline enforced by schema: safe.
- Naive with no discipline: shift guaranteed for any producer whose locale differs from the consumer's assumed zone.
- Mixed: worst case; some timestamps are correct, some shifted, and no filter distinguishes them.

## Operational Effect

The defect is proportional to the producer's timezone offset, which changes twice a year for DST, so it can shift by an hour without any code change. Remediation is offset-enforcement in the schema. The trap is to append `Z` in the parser. That assumes the producer already meant UTC, which is exactly the assumption in question.

```python
import re
from dataclasses import dataclass


class NaiveTimestampError(ValueError):
    """Raised when a timestamp lacks a timezone and its instant is ambiguous."""


OFFSET_RE = re.compile(r"(Z|[+-]\d{2}:?\d{2})$")


@dataclass(frozen=True)
class TimestampGate:
    value: str
    naive_means_utc: bool = False

    def verify(self) -> bool:
        if OFFSET_RE.search(self.value):
            return True
        if not self.naive_means_utc:
            raise NaiveTimestampError(
                "timestamp lacks timezone; producer and consumer may disagree on the instant"
            )
        return True


def dispatch_timestamp_parse(gate: TimestampGate) -> str:
    try:
        gate.verify()
    except NaiveTimestampError:
        return "reject-naive"
    return "parse"
```