Date and Time on the Internet: Timestamps

RFC 3339 — Informational
Published: July 2002
Authors: G. Klyne, C. Newman

Abstract

RFC 3339 defines an Internet profile of ISO 8601 for the representation of dates and times as character strings. It specifies a restricted, unambiguous format intended for use in Internet protocols where interoperability requires a single, well-defined timestamp representation. The profile eliminates the flexibility of ISO 8601 in favor of a fixed, machine-parseable grammar.

1. Introduction

Internet protocols frequently need to express timestamps — in HTTP headers, email messages, log files, data feeds, and APIs. ISO 8601 permits many equivalent representations of the same moment in time, creating interoperability problems when different systems produce different forms. RFC 3339 solves this by defining a single canonical profile: one grammar, one set of allowed forms.

The format is designed to be:

Sortable — lexicographic sort produces chronological order when all timestamps use the same offset.
Human-readable — fixed separators and digit counts allow visual inspection.
Machine-parseable — the grammar is unambiguous and regular.

2. Terminology

Term	Meaning
UTC	Coordinated Universal Time — the basis for civil time worldwide
Offset	Difference between local civil time and UTC, expressed as `+HH:MM` or `-HH:MM`
`Z`	Literal suffix indicating zero UTC offset (equivalent to `+00:00`, preferred for UTC)
Leap second	An extra second inserted at the end of a UTC minute to keep UTC close to solar time
ABNF	Augmented Backus-Naur Form — the grammar notation used in RFC 3339

3. Timestamp Format

An RFC 3339 timestamp combines a full date, a separator, a full time, and a UTC offset:

date-time = full-date "T" full-time
full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset

The T separator between the date and time portions MAY be replaced by a single space character if both the sender and receiver agree in advance. No other separator substitution is permitted.

4. ABNF Grammar

The normative grammar for a conforming timestamp:

date-fullyear   = 4DIGIT
date-month      = 2DIGIT            ; 01-12
date-mday       = 2DIGIT            ; 01-28 / 01-29 / 01-30 / 01-31

time-hour       = 2DIGIT            ; 00-23
time-minute     = 2DIGIT            ; 00-59
time-second     = 2DIGIT            ; 00-58 / 00-59 / 00-60 (leap second)
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

5. Component Rules

5.1 Date Component

The date uses the proleptic Gregorian calendar. Year is always four decimal digits. Month and day are zero-padded to two digits.

5.2 Time Component

Hours, minutes, and seconds are zero-padded to two digits. The seconds field ranges from 00 to 60; the value 60 represents a positive leap second and MUST be accepted by conforming receivers.

5.3 Fractional Seconds

The fractional seconds component is optional. It consists of a literal period followed by one or more decimal digits. No maximum length is imposed. Implementations MUST NOT assume a fixed precision and MUST preserve the full digit string when forwarding.

5.4 UTC Offset

The offset Z denotes UTC and is the preferred notation when the time zone is known to be UTC. A numeric offset +HH:MM or -HH:MM denotes the civil time offset in effect at the stated time. Negative offsets west of UTC are represented with a minus sign.

The offset -00:00 has a specific meaning in some contexts (unknown local offset) and SHOULD be avoided in new usage; use Z for UTC.

6. Examples

Timestamp	Interpretation
`1985-04-12T23:20:50.52Z`	12 April 1985, 23:20:50.52 UTC
`1996-12-19T16:39:57-08:00`	19 December 1996, 16:39:57 at UTC-8 (Pacific Standard Time)
`1990-12-31T23:59:60Z`	31 December 1990, 23:59:60 UTC — a positive leap second
`1937-01-01T12:00:27.87+00:20`	1 January 1937, 12:00:27.87 at UTC+0:20 (historical Dutch civil time)

7. Restrictions over ISO 8601

RFC 3339 is a strict subset of ISO 8601. The following ISO 8601 forms are explicitly excluded from the RFC 3339 profile:

Excluded Form	Example	Reason
Week dates	`1985-W15-5`	Ambiguous without ISO 8601 week numbering context
Ordinal dates	`1985-102`	Requires day-of-year arithmetic not needed for interchange
Truncated formats	`85-04-12`	Two-digit years introduce year-2000-class ambiguity
Expanded years	`+001985-04-12`	Not needed for the foreseeable date range
Midnight as 24:00:00	`1985-04-13T24:00:00Z`	Equivalent to `1985-04-13T00:00:00Z`; prefer the latter

These restrictions mean any RFC 3339 timestamp can be parsed by the fixed grammar above without branching for alternative ISO 8601 variants.

8. Security Considerations

Timestamps reflect the clock of the originating system, not an independently verified time. An attacker controlling a system can produce plausible but false timestamps. Applications that use timestamps for security-sensitive purposes — replay-attack prevention, certificate validity windows, audit log ordering — SHOULD:

Use an authenticated time source such as NTP (RFC 1305).
Validate that received timestamps are within an expected range.
Pair timestamps with cryptographic authentication (e.g., HMAC or digital signatures) when ordering guarantees are required.

Timestamps alone do not guarantee the integrity or ordering of events.

References

ISO 8601 — Representations of dates and times.
RFC 1305 — Mills, D., "Network Time Protocol (Version 3)", March 1992.
RFC 2234 — Crocker, D., Overell, P., "Augmented BNF for Syntax Specifications: ABNF", November 1997.
RFC 2822 — Resnick, P., "Internet Message Format", April 2001. (Email date format — related but distinct profile.)

id	`schema-atoms/rfc/rfc-3339`
authors	G. Klyne, C. Newman
created	2026-05-24