RFC 2822 vs ISO 8601: Two Timestamp Formats and When to Use Each

Open the raw source of any email and one line will read something like "Wed, 29 Jul 2026 03:14:07 +0000". Open a JSON payload from almost any modern API and you will see "2026-07-29T03:14:07Z" instead. Both name the same instant. The first follows RFC 2822, the internet message format specification; the second follows ISO 8601. Knowing which belongs where saves a good deal of parsing grief.

This page compares the two shapes field by field, explains where each is actually mandatory, introduces RFC 3339 as the strict profile that sits between them, and ends with a short rule for choosing. You can render the current moment in the standard form on the ISO 8601 formatter as you read.

What Is the RFC 2822 Date Format?

RFC 2822 is the 2001 specification for internet message format, and its date syntax is the one used in the Date header of every email. A conforming value looks like "Wed, 29 Jul 2026 03:14:07 +0000": optional weekday, day, three-letter month, four-digit year, time, then a signed four-digit offset.

Two details are worth pinning down. The document supersedes RFC 822 from 1982 and was itself superseded by RFC 5322 in 2008, so the strictly correct modern citation is RFC 5322 even though almost everyone still says RFC 2822 out of habit; the date syntax is materially the same in both. Second, the offset is four digits with no colon, as in +0530, which is not the shape ISO 8601 uses. RFC 2822 also tolerates a set of obsolete alphabetic zones inherited from its predecessor, including UT, GMT and the North American abbreviations, and it instructs parsers to treat single-letter military zone names as an unknown offset because the older document defined their signs backwards.

How RFC 2822 and ISO 8601 Differ

ISO 8601 orders its fields largest to smallest, uses only digits, and separates date from time with the letter T. The same instant becomes 2026-07-29T03:14:07Z, where Z stands for a zero offset against Coordinated Universal Time.

The practical consequences follow from the ordering. An ISO string sorts chronologically when sorted as text, has a fixed length for a given precision, and requires no lookup table of month names or weekday abbreviations to parse. The RFC 2822 form has none of those properties: "Apr" must be recognised as a word, the day may be one or two digits, and sorting a column of such values alphabetically yields nonsense. The trade is readability for a human skimming a header, which is exactly what email was designed for. The ordering rules are set out in full in ISO 8601 explained.

Is the HTTP Date Header the Same Thing?

No, and this is the single most common misconception in the area. HTTP defines its own fixed-width date, derived from the same ancestor but not interchangeable with the email syntax: "Sun, 06 Nov 1994 08:49:37 GMT".

The differences are small and strictly enforced. The weekday is mandatory rather than optional, the day is always two digits with a leading zero, and the zone must be the literal string GMT rather than a numeric offset. A server that emits an RFC 2822 style "+0000" in a Date, Expires or Last-Modified header is out of specification, even though the instant is identical. In JavaScript, the toUTCString method on a Date produces exactly this HTTP shape, while toISOString produces the standard one, and confusing the two methods is a reliable source of caching bugs.

Where RFC 3339 Fits In

RFC 3339 is a tightened profile of ISO 8601 written specifically for internet protocols. It keeps the shape people recognise and removes the optional variations that make a general-purpose parser hard to write.

• Four-digit year required: no truncated or expanded year forms.
• Offset required: every timestamp must end in Z or a signed hh:mm, so a bare local time is not valid.
• Colon in the offset: +05:30, not the +0530 that RFC 2822 requires.
• -00:00 has a meaning: uniquely, it signals that the instant is known but the local offset is not, which the parent standard does not permit at all.
• Optional forms dropped: week dates, ordinal dates, durations and reduced precision are all outside the profile.

A more recent extension, RFC 9557, adds a bracketed zone identifier to the end, so 2026-07-29T05:14:07+02:00[Europe/Berlin] records the instant and the region's rule set together. That combination is the correct way to express a future appointment, as argued in why you should store dates in UTC.

Parsing Timestamps You Did Not Write

Reading dates from the outside world is harder than emitting them, because you inherit every historical liberty a sender has taken. A few habits make it survivable.

Use a library rather than a regular expression. The email syntax alone permits optional weekdays, one or two digit days, obsolete alphabetic zones and folded whitespace between any two tokens, and a pattern that handles all of it correctly is longer than the specification is worth reading. Every mainstream language ships a parser for the RFC 2822 shape and another for the standard one, and both are better tested than anything written in an afternoon. Convert to a single internal instant at the boundary, discard the original string once you have a value you trust, and record the offset separately if the sender's local time is itself meaningful data. Where a timestamp arrives with no offset at all, do not silently assume UTC and do not silently assume the server's zone; treat it as incomplete input and say so, because a guess made at parse time is impossible to detect afterwards.

Which Format Should You Use?

Use RFC 2822 only where a specification demands it, and ISO 8601 or its RFC 3339 profile everywhere else. The rule is nearly that simple, because the older syntax exists for compatibility rather than for merit.

• Email headers: RFC 2822 syntax, because mail transfer agents expect it and some will reject a message without a conforming Date line.
• HTTP headers: the fixed-width GMT form described above, which your framework almost certainly generates for you.
• JSON and APIs: RFC 3339, always with an explicit offset.
• Logs and filenames: the standard form, because it sorts as text and merges cleanly across machines.
• Internal storage: an instant, kept in UTC, with a zone identifier held separately when the local calendar matters.

When parsing rather than writing, be generous: accept both shapes, normalise immediately to a single internal representation, and never pass a raw header string further into the system. Checking what offset your own machine reports is a useful first step, and the UTC offset detector will tell you.

Conclusion

RFC 2822 and ISO 8601 solve the same problem for different readers. The RFC 2822 date, still the law of the land in email, is written to be skimmed by a person and carries weekday and month names to prove it. ISO 8601, and the RFC 3339 profile that tightens it, is written to be parsed, sorted and compared. Emit the standard form unless a protocol forces your hand, and normalise everything you receive. Convert any timestamp between them with the ISO 8601 formatter, compare regional conventions in date formats around the world, or start from the current instant on localdatetime.now.