Every JSON API response you've ever parsed that contained a timestamp like 2026-09-01T14:23:45Z owes its unambiguous readability to a modest 18-page RFC from July 2002. RFC 3339 is a profile of ISO 8601 — a strict subset that trims away the many optional forms of the international standard so that machines and humans can agree on exactly one interpretation of a date-time string.

The problem it solves. Before 3339, internet protocols were a menagerie of date formats. RFC 822 (email) used Mon, 01 Sep 26 14:23:45 -0500. HTTP used a fixed-width variant defined in RFC 1123. Unix tools used ctime. Windows had its own. ISO 8601 existed but was (and still is) locked behind a CHF 158 paywall from ISO, and it permits dozens of legal variants: 20260901T142345Z, 2026-09-01T14:23:45+00:00, week-of-year notation, ordinal dates, truncated forms. You cannot build interop on "pick your favorite subset."

What 3339 actually constrains. Klyne and Newman picked a single opinionated shape:

• Four-digit years, always. YYYY-MM-DD with hyphens.
• Literal T between date and time (lowercase t or space are permitted as alternatives, but T is canonical).
• 24-hour clock, zero-padded. Fractional seconds allowed with arbitrary precision.
• A time offset is mandatory: either Z for UTC or ±hh:mm. No "naive" datetimes. This is the single most important design decision in the document.
• Leap seconds are permitted (23:59:60Z), which trips up almost every parser ever written.

The quirky bit: -00:00. Section 4.3 distinguishes +00:00 (known to be UTC) from -00:00 (local time whose offset is unknown, but we know it's not UTC). Almost nobody honors this. Postgres, Python's datetime, JavaScript's Date, and Go's time.Parse all treat them identically. It's the appendix nobody read.

Why it matters in 2026. RFC 3339 is the de facto timestamp format for JSON, YAML front-matter, OpenAPI, JSON Schema ("format": "date-time"), Kubernetes manifests, systemd journal exports, OAuth tokens, and every logging pipeline from Loki to CloudWatch. When JSON Schema says "date-time," it means 3339, not 8601. When your Rust chrono or Go time.RFC3339 constant serializes a timestamp, this is the shape it produces.

The gap it left, and RFC 9557. 3339 tells you the instant but not the civil location. 2026-09-01T14:23:45-04:00 could be Eastern Daylight Time or Atlantic Standard Time — the offset alone can't tell you which, and it certainly can't survive a DST transition. In April 2024 the IETF published RFC 9557, which extends 3339 with a bracketed IANA zone suffix: 2026-09-01T14:23:45-04:00[America/New_York]. This is what Temporal (the new JavaScript date API) and the JDK's ZonedDateTime emit. If you're designing a scheduling system today, prefer 9557; if you're stamping log lines, 3339 is still exactly right.

The backstory. Chris Newman was deep in the IMAP/SIEVE world and kept running into date-parsing ambiguity across mail extensions. Graham Klyne was writing metadata specs (he later co-authored the URI RFC 3986). The two collaborated to produce something short, prescriptive, and free — a deliberate counter to ISO's paywalled sprawl. Twenty-four years later it is arguably the most-implemented date format in software.