RSS Date Formats Explained: RFC 822 pubDate Errors and Fixes

Short answer: In RSS 2.0, pubDate dan lastBuildDate must use the RFC 822 date format, for example Tue, 29 Sep 2026 08:00:00 +0000: an English weekday and month abbreviation, a four-digit year, a 24-hour time and a time zone. The most common errors are ISO 8601 dates, translated month names, missing or malformed time zones and local times labelled as GMT. Generate dates with your language’s built-in RFC 822 or RFC 2822 formatter instead of building strings by hand.

Why feed dates matter more than they seem

A date in an RSS feed looks like a detail. In practice, it drives a surprising amount of behaviour. Feed readers use it to sort items and show “2 hours ago”. Aggregators use it to decide what is recent. Auto-posting tools use it, together with the item’s GUID, to decide whether an item is new, whether it falls after a configured start date, and in which order to publish several new items. Search engines and news aggregators may use it as a signal of freshness.

When the date is wrong or unreadable, the symptoms are confusing. An article published this morning appears at the bottom of a reader’s list. An auto-poster skips a new item because it looks older than the start date. Items are posted in the wrong order. Or a validator reports an error that nobody understands, because the date “looks fine” to a human.

Most of these problems come down to one thing: RSS 2.0 expects a very specific, somewhat old-fashioned date format, and modern software often produces something else.

The RFC 822 format, piece by piece

The RSS 2.0 specification says that all date-times conform to the Date and Time Specification of RFC 822, with the exception that the year may be two or four digits, four being preferred. A correct example:

<pubDate>Tue, 29 Sep 2026 08:00:00 +0000</pubDate>

Broken into parts:

• Weekday (optional): Mon, Tue, Wed, Thu, Fri, Sat atau Sun, followed by a comma. It must match the actual date.
• Day: one or two digits, for example 1 atau 01 atau 29.
• Month: a three-letter English abbreviation: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec.
• Year: four digits, such as 2026.
• Time: 24-hour HH:MM atau HH:MM:SS.
• Time zone: either a numeric offset such as +0000, +0300 atau -0500, or a named zone such as GMT atau UT. RFC 822 also allows a few US zone names like EST dan PDT, but numeric offsets are clearer and safer.

The original standard is RFC 822, published in 1982 for e-mail headers. Its successors, RFC 2822 and RFC 5322, use essentially the same format with a four-digit year, which is why “RFC 2822 date” functions in programming languages produce valid RSS dates.

The most common pubDate errors

These errors appear again and again in real-world feeds:

Some parsers are lenient and cope with several of these. Others are strict and either reject the date, fall back to the time they fetched the feed, or treat the item as undated. Because you cannot control which parser a reader or tool uses, the only safe approach is a correct date.

The silent error: wrong time zone

A date can be perfectly formatted and still wrong. The most common case is a server that writes local time but labels it GMT atau +0000. A post published at 09:00 in Vilnius (UTC+3 in summer) then appears as if it were published at 09:00 UTC, three hours in the future. Some tools hold future-dated items until their date arrives; others ignore them; readers may sort them above genuinely newer items.

The reverse also happens: a US site writes UTC time but labels it -0500, pushing items five hours into the past. If an auto-poster is configured to post only items newer than a start time, items can fall on the wrong side of that line.

To check, publish a test post, note the real time and compare it with the feed. Convert both to UTC. They should match within a minute. Daylight saving changes are a classic trigger for this bug, because offsets change twice a year in many countries. Our article on time zones and daylight saving in auto-posting covers the related scheduling questions.

How date errors affect auto-posting

Auto-posting tools mainly use GUIDs and links to recognise new items, but dates still play several roles:

• Start date filters. When you connect a feed and choose to post only items published after a certain date, the tool compares each item’s pubDate with that date. Wrong dates mean wrong decisions.
• Catching up older items. If a tool can publish older items from a chosen date onward, it relies on dates to know which ones qualify.
• Order. When several new items appear at once, tools often publish them oldest first or newest first based on pubDate.
• Backdated and future posts. Items with dates far in the past or future may be treated specially. See feed order and backdated posts.
• Freshness displays. Some networks show the time of the social post, not the article, but readers who click through will notice if dates do not add up.

An unparseable date does not always break automation, because GUIDs still identify new items. But it removes the safety net that dates provide, and it makes troubleshooting much harder.

Generating correct dates in code

The reliable fix is never to build date strings by hand. Every mainstream language has a function that produces RFC 822 or RFC 2822 dates:

• PHP: date(DATE_RSS, $timestamp) atau $dt->format(DATE_RSS). Both produce English names regardless of locale settings. Avoid functions that follow the system locale for this purpose.
• Python: email.utils.format_datetime(dt) with a timezone-aware datetime, or email.utils.formatdate(ts, usegmt=True).
• JavaScript: new Date(ts).toUTCString() returns a string such as Tue, 29 Sep 2026 08:00:00 GMT, which is valid.
• Ruby: time.rfc2822 atau time.httpdate.
• C#: dt.ToUniversalTime().ToString("r") produces an RFC 1123 date in GMT.
• Go: t.Format(time.RFC1123Z).

Two rules apply everywhere: start from a timezone-aware value (or convert to UTC first), and use the formatter’s fixed English output rather than locale-dependent formatting. Many CMS platforms do this correctly out of the box; problems usually come from custom templates or plugins that format dates themselves.

Diagnosing date problems step by step

1. Look at the raw feed. Open the feed URL and find the pubDate of the newest item. Compare its format with the examples above.
2. Run a validator. The W3C Feed Validation Service flags invalid RFC 822 dates explicitly, including weekday mismatches.
3. Check the time zone. Convert the feed date to UTC and compare it with when you actually published.
4. Find the source. If the platform’s default feed is correct but yours is not, a theme template, a feed plugin or a custom field is formatting dates. Check it after every update.
5. Test in a reader. Subscribe in a feed reader and see whether the new item appears with the right relative time.

Fix the source, not the symptom. Adjusting settings in every tool that reads your feed is endless work; a correct feed fixes all of them at once.

Edge cases worth knowing

Beyond the common errors, a few less obvious situations cause trouble in real feeds:

• Two-digit years. RFC 822 originally used two-digit years, and the RSS specification still allows them, but four digits are preferred. A date like 29 Sep 26 forces the parser to guess the century. Always write four digits.
• Missing dates. pubDate is optional in RSS 2.0, so some feeds omit it entirely. Tools then fall back on the order of items or on the time they first saw each item. That works, but start-date filters and ordering options become unreliable. If you control the feed, add dates.
• Identical dates for every item. Some generators stamp every item with the time the feed was built rather than the time each item was published. Every item then looks brand new on each rebuild, and ordering becomes meaningless.
• Dates that change on edit. If a template uses the “modified” date as pubDate, fixing a typo in an old article moves it to the top of the feed. Readers and tools may treat it as new content. Use the original publication date for pubDate.
• Scheduled posts. A post scheduled for tomorrow should not appear in the feed until it is published. If it does, with a future date, tools may post it early or hold it; neither is what you intended.
• Extra whitespace and line breaks. A pubDate that contains a newline or leading spaces, often produced by template formatting, can fail in strict parsers. Keep the element on one line.

Each of these is easy to check in the raw XML, and each is easy to fix in the template that produces the feed.

What about Atom and lastBuildDate?

If your platform offers an Atom feed, dates there follow RFC 3339, a profile of ISO 8601, such as 2026-09-29T08:00:00Z atau 2026-09-29T11:00:00+03:00. Here the colon in the offset is correct. Mixing the two formats, ISO dates in RSS or RFC 822 dates in Atom, is a common mistake when templates are copied between formats.

In RSS, lastBuildDate on the channel uses the same RFC 822 format as pubDate. It should reflect the last time the feed content changed. Some tools use it as a hint about whether anything is new, so a lastBuildDate that never changes, or changes on every request, is worth fixing too. The differences between the two are explained in pubDate vs lastBuildDate.

How PostRSS reads your dates

PostRSS reads RSS 2.0 and Atom feeds and checks them every 5 minutes on all plans, or every minute on Enterprise plans. You can choose whether newer or older items are published first, set the maximum number of posts per update, and pick a date to start from so that older items that were never published are caught up. Those options depend on accurate item dates, which is why a correctly formatted pubDate makes setup predictable. See the features page for all options and the pricing page for plans.

Related reading

• RSS Feed XML Anatomy Explained: What GUID and pubDate Actually Do
• RSS Feed Validation Before You Auto-Post
• How to Write an RSS Feed by Hand: A Minimal Valid Example

The bottom line

RSS 2.0 dates must follow RFC 822: English weekday and month abbreviations, a four-digit year, a 24-hour time and a time zone offset without a colon. Most date problems come from ISO dates, localised names, missing offsets or local time mislabelled as GMT. Generate dates with a standard library formatter from a timezone-aware value, validate the feed, and compare the feed time with the real publication time once.

It is a small fix with a large payoff: once dates are right, readers sort your items correctly, validators stop complaining and every tool that depends on your feed behaves predictably, from start-date filters to posting order.

FAQ

What date format does RSS pubDate use?

RSS 2.0 uses the RFC 822 format with a four-digit year, for example Tue, 29 Sep 2026 08:00:00 +0000. The weekday is optional, but if present it must match the date.

Can I use ISO 8601 dates in an RSS feed?

Not in pubDate or lastBuildDate. ISO 8601 dates such as 2026-09-29T08:00:00Z are correct in Atom feeds, but in RSS 2.0 they are invalid and some parsers will ignore them.

Is +00:00 a valid time zone in RSS?

No. RFC 822 offsets have no colon, so write +0000. GMT and UT are also accepted. The colon form belongs to ISO 8601 and RFC 3339, which Atom uses.

Why does my feed show German or French month names?

The template formats dates with a locale-dependent function. Switch to a fixed RFC 822 or RFC 2822 formatter, such as DATE_RSS in PHP, which always produces English names.

Will a wrong date stop auto-posting?

Not always, because tools mainly use GUIDs to spot new items. But wrong dates can cause items to be skipped by start-date filters, posted in the wrong order or treated as future items, so it is worth fixing.