Date and time · date formatsRFC 2822 date — email and HTTP
RFC 2822 is the date format of the email Date: header, RSS and HTTP: Sat, 03 Oct 2026 14:30:00 +0300. Paste a string and the tool breaks it into parts, converts it to your time zone and says what is wrong with it: a mismatched weekday, a two-digit year, a zone name instead of an offset.
Calculated in your browser — values are never sent anywhere
The format is defined in RFC 2822 (2001) and lives on in RFC 5322 unchanged. The order: weekday, day, three-letter month, four-digit year, time, and the offset from UTC as four digits with a sign.
HTTP uses the same format with one restriction (RFC 7231, IMF-fixdate): the time is always GMT and the weekday is mandatory. Last-Modified, Expires and Date in server responses look like this, and so does JavaScript's toUTCString().
The standard lets you read obsolete forms — a two-digit year, zone names UT, GMT, EST, PST — but not write them. The offset -0000 means not “Greenwich” but “the sender's local time is unknown”.
Part by partSat, 03 Oct 2026 14:30:00 +0300
Sat,
weekday — must match the date
03 Oct 2026
day, three-letter English month, four-digit year
14:30:00
the sender's time; seconds are optional
+0300
offset from UTC: +0300 is Moscow, -0000 is “unknown”
How to do it yourself
new Date().toUTCString()JavaScript: an HTTP date in GMT
date -RLinux: the current date in RFC 2822 with the local offset
2026-10-03 11:30 UTC · two-digit year, local time unknown
04
Common mistakes
A localised month or weekday (“Okt”, “Sa.”) — no mail client or parser will read it: the format allows only English three-letter abbreviations.
A zone name such as MSK, CET or IST. The standard knows only the US names and GMT; others are ambiguous — IST is both India and Ireland. Write the offset: +0300.
A weekday that does not match the date — the sign of a hand-built or templated string. Many parsers silently take the day number and ignore the weekday, so the bug survives into production.
05
Frequently asked
Sat, 03 Oct 2026 14:30:00 +0300 — weekday, day, three-letter English month, four-digit year, time and the offset from UTC. It is the date line of every email's Date: header and of RSS feeds, and, in its always-GMT form, of HTTP headers. The current standard is RFC 5322, but the date format in it is unchanged.
ISO 8601 writes from largest to smallest in digits — 2026-10-03T14:30:00+03:00 — and sorts as text, which is why databases and APIs prefer it. RFC 2822 is friendlier to read, but the month and weekday are words and the offset has no colon. Converting between them is lossless: the moment is the same, only the notation changes.
That the sender's local time is unknown. The standard separates +0000 — “this is Greenwich time” — from -0000 — “the time is given in UTC because the system does not know its own zone”. The moment is identical; the only difference is whether you may infer the sender's zone. Mail robots and servers without a configured zone often write it.
IMF-fixdate from the HTTP standard (RFC 9110, formerly RFC 7231): Sat, 03 Oct 2026 11:30:00 GMT. It is RFC 2822 with two restrictions: the time is always GMT and the weekday is mandatory. Date, Last-Modified, Expires and If-Modified-Since use it. Servers must still accept the obsolete RFC 850 and asctime forms, but must not send them.
The string was assembled by hand or by a template, and the weekday was not recalculated from the date. Mail clients usually take the day and month and ignore the weekday, so the bug survives for years unnoticed — for example in newsletters that insert the date from settings. Check the string on this page: on a mismatch the tool names the real day.
In JavaScript, toUTCString() returns the HTTP form with GMT: Sat, 03 Oct 2026 11:30:00 GMT. It never writes offsets such as +0300 — build one by hand or use a library. Python has email.utils.format_datetime(datetime) for a zone-aware moment and email.utils.formatdate(localtime=True) for now. On Linux, date -R does it.