Is RFC 3339 the same as ISO 8601?

No. RFC 3339 is a restricted profile of ISO 8601. It removes optional features, mandates the `T` separator, and requires every timestamp to include a timezone. Everything valid in RFC 3339 is valid in ISO 8601. The reverse is not true.

Why does my email client show a different time than my API?

Email uses RFC 2822 with a numeric offset from UTC. Your API uses ISO 8601 with a `Z` or offset. Both represent the same instant. Your email client applies your local timezone rules. Your API may be returning UTC directly.

Can I use a space instead of the T in RFC 3339?

Yes. RFC 3339 permits a space as an alternative to the `T` separator. The `T` is preferred. ISO 8601:2019 discourages the space. Stick with `T` for new code.

What does the Z mean in a timestamp?

`Z` stands for "Zulu" and means the time is in UTC with zero offset. It is equivalent to writing `+00:00`. A timestamp without a `Z` or offset is local time. That is ambiguous. Avoid it in APIs.

Is the HTTP Date header the same as RFC 2822?

No. The HTTP `Date` header looks similar but is defined separately. The weekday is mandatory. The day is always two digits. The zone must be the literal string `GMT`. RFC 2822 allows numeric offsets and a one-digit day. Check the HTTP specification for the exact requirements.

Should I store timestamps in UTC or local time?

Store in UTC. UTC is an instant in time, independent of timezone. Local time is a display format. If you store local time without an offset, you cannot recover the instant. You will have bugs during daylight saving transitions.

RFC 2822 vs ISO 8601: Which Date Format Should You Use?

Open a raw email and the Date: header reads Wed, 29 Jul 2026 03:14:07 +0000. That shape is RFC 2822, frozen in place since 2001. Now call any modern API. The timestamp comes back as 2026-07-29T03:14:07Z. That is RFC 3339, the internet's strict profile of ISO 8601. One format was built for humans skimming a header. The other sorts correctly as text. Emit the second one. Parse the first.

What is RFC 2822?

RFC 2822 is the 2001 specification for internet message format. It obsoleted RFC 822 from 1982, the original ARPANET standard for text messages. The date format in email headers has not changed across those revisions. It is frozen by legacy. Changing it would break every mail client, archive system, and mailing list parser ever written.

The shape is rigid: Day, DD Mon YYYY hh:mm:ss ±hhmm. The weekday is mandatory. The day can be one or two digits. The offset is four digits with no colon: +0530, not +05:30. That missing colon is a reliable source of parser bugs when code confuses the two standards.

What is ISO 8601?

ISO 8601 is the international standard for date and time representation. First published in 1988, it merged several earlier ISO standards. The 2019 revision split it into two parts: ISO 8601-1 for basic rules and ISO 8601-2 for extensions like uncertain dates and sets.

The extended format orders every field largest to smallest:

2026-07-29T03:14:07+05:30

Year, month, day. Then T. Then hour, minute, second. The timezone offset uses a colon between hours and minutes. Z means UTC.

ISO 8601 has a property no other format shares: a lexicographic sort of ISO strings is a chronological sort. That single fact makes it the default for log files, database timestamps, and API payloads.

RFC 3339: the profile that matters for APIs

RFC 3339, published in 2002, defines a strict profile of ISO 8601 for internet protocols. It removes the optional variations that make a general-purpose ISO parser hard to write.

RFC 3339 mandates the T separator, allows a space as an alternative, and requires every timestamp to end in either Z or a signed hh:mm offset. A bare local time without a zone is not valid. Expanded year forms and reduced precision are forbidden.

The result is what you see in every modern API:

2026-07-29T03:14:07Z

RFC 2822 vs ISO 8601: which sorts correctly?

Feature	RFC 2822	ISO 8601 / RFC 3339
Example	Wed, 29 Jul 2026 03:14:07 +0000	2026-07-29T03:14:07Z
Field order	Day, DD Mon YYYY	YYYY-MM-DD
Month name	Required (Jul)	Never (numeric only)
Time separator	Space	`T`
Offset format	`+0530` (no colon)	`+05:30` (colon)
Sorts chronologically	No	Yes
Human-readable at a glance	Yes	Less so
Parser complexity	Higher	Lower

The weekday in RFC 2822 is mandatory. The day is always two digits in ISO 8601 but may be one digit in RFC 2822. Parsing RFC 2822 requires recognising month names and weekday abbreviations. ISO 8601 has no lookup tables.

Where you encounter each format

Email headers are the last major stronghold of RFC 2822. Every message carries a Date: header in this format.

APIs and logs use ISO 8601 or RFC 3339. JSON payloads, database timestamps, and configuration files use the T and Z shape. JavaScript's toISOString() produces it. toUTCString() produces the HTTP form. Confusing the two is a reliable source of caching bugs.

Why email will not change

RFC 2822 was designed for humans skimming a header. "Wed, 29 Jul 2026" reads naturally, and the month name removes ambiguity about which field is which. ISO 8601 was designed for machines: every field is positional, fixed-width, and unambiguous.

Do not wait for email to migrate. The format is baked into every mail client, every mailing list archive, and every email-related RFC published since 1982. The cost of migrating is enormous. The benefit is zero. Write email software: parse RFC 2822. Write APIs: emit ISO 8601. The two worlds do not need to merge.

What to use for APIs and logs

Use RFC 3339 for anything new. It is ISO 8601 with the ambiguity removed. Store timestamps in UTC with a Z suffix. Let the client format for its local timezone. This single practice avoids the "off by one hour" class of bugs.

Skip RFC 2822 for anything you plan to sort, compare, or store in a database. The format does not sort correctly. The month names require locale tables. The variable-length day field makes fixed-width parsing impossible.