Add format_rfc2822() / parse_rfc2822() to ZonedDateTime

[Binilkks]

Feature Request: RFC 2822 support on ZonedDateTime

Problem

Both Instant and OffsetDateTime support RFC 2822 formatting and parsing:

Instant.parse_rfc2822("Sat, 15 Aug 2020 23:12:00 GMT")
OffsetDateTime.parse_rfc2822("Sat, 15 Aug 2020 23:12:00 +0200")

But ZonedDateTime — despite being the most feature-rich datetime type — has no RFC 2822 support.

Why it matters

RFC 2822 is used in:

• HTTP Date: response headers
• Email Date: fields

Users working with ZonedDateTime who need to produce HTTP headers or email dates currently have to convert first:

# Workaround today — clunky
zdt.to_fixed_offset().format_rfc2822()

This breaks the ergonomic flow and is easy to forget.

Expected Behavior

zdt = ZonedDateTime.now("America/New_York")
zdt.format_rfc2822()  # → "Thu, 26 Jun 2026 10:30:00 -0400"
ZonedDateTime.parse_rfc2822("Thu, 26 Jun 2026 10:30:00 -0400", tz="America/New_York")

For format_rfc2822(), the offset at that point in time can be resolved from the IANA timezone. For parse_rfc2822(), a tz parameter would be needed to assign the IANA timezone (similar to how assume_tz() works).

Consistency

Method	Instant	OffsetDateTime	ZonedDateTime
format_rfc2822()	✅	✅	❌
parse_rfc2822()	✅	✅	❌

Filling this gap would make ZonedDateTime consistent with the other exact-time types.

[ariebovenberg]

Hi @Binilkks thanks for posting this issue. I understand the apparent "gap" in the API, but I'm not convinced yet that it needs to be filled.

The current state explicitly reflects the fact that RFC2822 cannot be converted to a ZonedDateTime without additional information.

The current approach is explicit and only a few more characters to type:

# parsing
OffsetDateTime.parse_rfc2822(the_str).assume_tz('America/New_York')
# formatting
zdt.to_fixed_offset().format_rfc2822()

This has the additional benefit of keeping the "what if the offset mismatches" handling contained to assume_tz.

edit: additional note. Implementing RFC2822 on ZonedDateTime would almost certainly raise the question "should three-letter timezone abbreviations be resolved". This is an additional opportunity for unexpected behavior