RFC 2822 是互联网消息格式标准（Internet Message Format），由 IETF 于 2001 年发布，用于规范电子邮件和网络协议中的日期时间表示。其典型格式为：
Thu, 21 Dec 2024 15:30:00 +0800
包含：星期几缩写、日期、月份缩写、年份、时分秒和时区偏移。它是 RFC 822 的更新版本，广泛用于电子邮件（SMTP）、HTTP 协议头（如 Date、Last-Modified、Expires 头）以及 RSS/Atom 订阅源中。

RFC 2822：Thu, 21 Dec 2024 15:30:00 +0800 — 使用英文缩写，可读性强，主要用于互联网消息和HTTP协议。
ISO 8601：2024-12-21T15:30:00+08:00 — 纯数字格式，易于机器解析和排序，是API和数据库中的首选格式。
两者在时区表示上也不同：RFC 2822 使用 +0800（不含冒号），ISO 8601 使用 +08:00（含冒号）。在编程中，API 响应通常使用 ISO 8601，而电子邮件和HTTP头使用 RFC 2822。

电子邮件中，RFC 2822 日期出现在邮件头的 Date 字段，标识邮件的发送时间。例如：
Date: Thu, 21 Dec 2024 15:30:00 +0800
邮件客户端（如 Gmail、Outlook）会根据该字段显示邮件时间，并结合收件人时区进行转换。此外，邮件中的 Received 链、Reply-To 等头字段也可能包含 RFC 2822 格式的时间戳。正确格式化邮件日期对于邮件送达率和反垃圾邮件检测也有影响。

HTTP/1.1 协议中多个响应头使用 RFC 2822 格式（严格来说是 RFC 7231 更新的 HTTP 日期格式，但基本一致）：
• Date：服务器响应时间
• Last-Modified：资源最后修改时间
• Expires：缓存过期时间
• If-Modified-Since：条件请求头
例如：Last-Modified: Thu, 21 Dec 2024 07:30:00 GMT
浏览器和CDN依据这些头信息进行缓存控制，正确的日期格式对Web性能优化至关重要。

RFC 2822 支持两种时区表示方式：
1. 数字偏移（推荐）：+0800、-0500、+0000，格式为 ±HHMM，范围从 -1200 到 +1400。
2. 字母时区（已过时但兼容）：如 GMT、UT、EST、EDT、PST、PDT 等。由于夏令时等因素，字母时区不够精确，现代应用推荐使用数字偏移。
注意：UTC 使用 +0000，虽然 GMT 仍广泛见于 HTTP 头中（如 Thu, 21 Dec 2024 15:30:00 GMT），GMT 与 UTC 在实践中等效。

• JavaScript：new Date().toUTCString() 返回类似格式（时区固定为 GMT）
• Python：email.utils.format_datetime() 或 datetime.now().strftime('%a, %d %b %Y %H:%M:%S %z')
• PHP：date('r') 或 date(DATE_RFC2822)
• Java：DateTimeFormatter.RFC_1123_DATE_TIME
• Go：time.Now().Format(time.RFC1123Z)
• C#：DateTime.Now.ToString("r")
各语言的"RFC 2822"实现可能有细微差异（如时区表示），建议测试确认。

这三个标准一脉相承：
• RFC 822（1982年）：最早定义互联网消息日期格式，允许2位年份。
• RFC 1123（1989年）：强制要求4位年份，解决Y2K问题，并推荐使用数字时区。
• RFC 2822（2001年）：整合并取代 RFC 822，澄清了诸多细节，是当前互联网消息格式的正式标准。
实际上 HTTP/1.1 规范引用的是 RFC 1123 的日期格式（通常称为 HTTP-date），而 RFC 2822 主要用于电子邮件。两者在日常使用中基本可以互换，格式几乎一致。

RFC 2822 源自英语互联网标准，其规范明确定义了3字母英文缩写：
星期：Mon, Tue, Wed, Thu, Fri, Sat, Sun
月份：Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
这是因为早期互联网协议设计时以英语为通用语言，且这些缩写被硬编码在标准中。使用其他语言的缩写会导致邮件服务器、HTTP客户端解析失败。因此，无论在全球任何地区，RFC 2822 日期中的星期和月份必须使用英文缩写。